Stream all CloudWatch metrics to Firehose, transform with Lambda, and deliver to S3
A company runs several applications in the same AWS account. The applications send logs to Amazon CloudWatch. A data analytics team needs to collect performance metrics and custom metrics from the applications. The analytics team needs to transform the metrics data before storing the data in an Amazon S3 bucket. The analytics team must automatically collect any new metrics that are added to the CloudWatch namespace. Which solution will meet these requirements with the LEAST operational overhead?
Community Votes
55% of anonymous learners picked answer B. Votes are pick records left by other test-takers — they are not the verified answer.
Community Insight
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.
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.
Community Discussion (5 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
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
Related Analysis
Practice All DOP-C02 Questions
Access 85 questions with complete answers and detailed explanations.
View Full DOP-C02 Practice Test →