Stream all CloudWatch metrics to Firehose, transform with Lambda, and deliver to S3
Short answer
B Stream all CloudWatch metrics to Firehose, transform them with a Lambda function, and deliver to S3.
Question
Key Takeaways
The binding constraint is that new metrics added to the namespace later must be collected automatically, which means the metric stream must be configured to include all metrics rather than an enumerated subset; an explicitly listed subset would need manual updating whenever a metric is added (B rather than A). Data Firehose provides the transformation hook through a Lambda function, so the Firehose-to-Lambda-to-S3 chain satisfies the transform-and-store requirement. Option C uses metric filters to create custom metrics and then streams directly to S3, which both derives metrics rather than collecting existing ones and omits any transformation step. Option D subscribes to log data rather than metrics.
The analytics team must collect both performance metrics and custom metrics, transform the data, store it in Amazon S3, and automatically pick up any metric added to the namespace later. A CloudWatch metric stream configured to include all metrics delivers every current and future metric to an Amazon Data Firehose delivery stream; Firehose invokes an AWS Lambda function to transform the data and then writes the transformed records into the S3 bucket. Selecting all metrics rather than a fixed subset is what satisfies the automatic-collection requirement.
Common mistake: Configuring the metric stream to include only metrics from the application and the CloudWatch namespace (A) — naming specific metrics means any metric added to the namespace later must be added to the stream configuration manually, which fails the automatic-collection requirement; rinip86277 and CHRIS12722222 both emphasized this distinction, with CHRIS12722222 noting that collecting all metrics in the namespace also captures new ones added later. Using metric filters to create custom metrics and streaming straight to S3 (C) — metric filters derive new metrics from log patterns rather than collecting the application's existing performance and custom metrics, and no transformation is performed before storage. Using subscription filters on log groups (D) — subscription filters deliver log events, not metric data, so the application's metrics would never be collected.
Expert Analysis
Why the Answer Is Correct
The requirement to automatically collect any metric later added to the namespace is the decisive constraint, and it is satisfied by configuring the CloudWatch metric stream to include all metrics rather than an enumerated selection. A metric stream delivers its metrics in near real time to an Amazon Data Firehose delivery stream, and Firehose can invoke an AWS Lambda function to transform the records before writing them to Amazon S3, which delivers the transform-then-store behavior with no custom pipeline code (B). Because the stream covers all metrics in the namespace, performance metrics, custom metrics, and any future additions are all captured without further configuration.
Why the Other Options Are Wrong
A configures the metric stream to include metrics from the application and the CloudWatch namespace, which reads as a specific selection of metrics rather than all metrics. Any metric added to the namespace after that configuration would not be streamed until the configuration was manually updated, which fails the explicit requirement for automatic collection of new metrics. uncledana and Ky_24 favored A, but the automatic-collection requirement decides it. C configures metric filters for CloudWatch logs to create custom metrics and then configures a metric stream to deliver the application metrics directly to S3. Metric filters derive new metrics from log patterns rather than collecting the existing performance and custom metrics the team asked for, and the stream goes straight to S3 with no transformation step, so two requirements go unmet. D configures subscription filters on the application log groups targeting a Firehose delivery stream. Subscription filters deliver log event data, not metric data, so the application's metrics would never reach Firehose at all. B is the correct answer.
Community Comment Notes
Community was closely split, B (55) versus A (45). rinip86277 and CHRIS12722222 argued for B on the decisive point that new metrics must be collected automatically, which requires selecting all metrics rather than naming specific ones; CHRIS12722222 noted that collecting all metrics in the namespace also captures new ones added later. Srikantha supported B for the same reason. uncledana and Ky_24 favored A, and uncledana restated the four requirements including automatic inclusion of new metrics, but the enumerated-selection reading of A conflicts with that last requirement.
Official Reference
https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Metric-Streams.html
This link opens the official vendor documentation in a new tab.
Community Votes
55% of anonymous learners picked answer B. Votes are pick records left by other test-takers — they are not the verified answer.
Discussion 5 contributions
Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.
From public community threads 5
-
CHRIS12722222 👍 4 Answered BWhy not option B? Just collect all the metrics in the namespace, if new ones are added later, it will also be collected
-
uncledana 👍 3 Answered AExplanation: The requirements are: 1. Collect performance metrics and custom metrics from CloudWatch. 2. Automatically include new metrics added to the namespace. 3. Transform the metrics data. 4. Store the transformed data in an S3 bucket. 5. Minimize operational overhead. Option A: Configure a CloudWatch metric stream to include metrics from the application and the CloudWatch namespace. Configure the metric stream to deliver the metrics to an Amazon Data Firehose delivery stream. Configure the Firehose delivery stream to invoke an AWS Lambda function to transform the data. Configure the delivery stream to send the transformed data to the S3 bucket.
-
Srikantha 👍 1 Answered BCloudWatch metric streams are designed specifically to stream metric data in near real-time to destinations like Firehose. Selecting "all metrics" ensures that any new metrics added in the future are automatically included, satisfying the requirement to "automatically collect any new metrics." Amazon Kinesis Data Firehose supports Lambda transforms, so the analytics team can modify data before it's delivered. Output to S3 is natively supported by Firehose, which satisfies the storage requirement.
-
rinip86277 👍 1 Answered BB is better than A because new metrics must be automatically collected. With A they have to be manually selected. With B they are automatically collected.
-
Ky_24 👍 2 Answered AA is correct
Reader comments & corrections
No reader corrections yet — spotted an error or have a note? Share it below.
Related Analysis
Practice All DOP-C02 Questions
Access 85 questions with complete answers and detailed explanations.
View Full DOP-C02 Practice Test →