DOP-C02 - Monitoring and Logging (15% of the exam) - Section 4.2

Aggregate telemetry across accounts and trace requests using CloudWatch cross-account observability, AWS X-Ray, Amazon Data Firehose and log subscription filters.

Centralise telemetry from many accounts using CloudWatch cross-account observability and route high-volume log streams to Amazon S3 or a data warehouse via Amazon Data Firehose. Instrument distributed services with AWS X-Ray to trace requests end to end and identify latency bottlenecks.

Cross-account observabilityAWS X-RayAmazon Data FirehoseSubscription filters

Practice question for this objective

Free sampleMonitoring and Loggingmedium

A company runs around forty AWS accounts under AWS Organizations, and each account writes application logs to its own Amazon CloudWatch Logs groups. The platform team needs all of these logs to flow continuously into a single logging account where they are indexed for search, and they want a near real-time, push-based mechanism that scales as new accounts and log groups appear. Which design meets this requirement with the least custom code?

ASchedule a Lambda function in every account to call the CloudWatch Logs GetLogEvents API on a timer and write the retrieved events into an Amazon S3 bucket owned by the central logging account.
BExport each log group to Amazon S3 with a daily CloudWatch Logs export task in every account and copy the resulting objects into the central logging account for later indexing.
CTurn on AWS CloudTrail organisation logging so every account delivers its CloudWatch Logs data to a central trail bucket that the logging account then indexes for full-text search.
DCreate CloudWatch Logs subscription filters in each account that send matching events to an Amazon Kinesis Data Streams destination in the central logging account, where a consumer indexes the events for search. Correct

Centralise CloudWatch Logs across many accounts in near real time using cross-account subscription filters to a shared destination. CloudWatch Logs subscription filters deliver matching log events to a configured destination, including an Amazon Kinesis stream owned by another account, as the events arrive. Pointing each account at a destination in the central logging account gives a push-based, continuously scaling aggregation path that needs only filter configuration rather than polling code or batch export jobs.

Why A is wrong: Polling GetLogEvents on a timer is custom code in every account, it lags behind real time, and tracking read positions across many log groups is brittle compared with the push-based subscription mechanism.

Why B is wrong: Log group export tasks are batch operations meant for archival and run on a schedule measured in hours, so they cannot satisfy the stated near real-time, continuous flow requirement.

Why C is wrong: CloudTrail records AWS API activity, not arbitrary application log content in CloudWatch Logs, so it captures the wrong data entirely and would not aggregate the application logs the team needs.

Why D is correct: Subscription filters push log events to a cross-account Kinesis destination in near real time and scale automatically as log groups are added, which is the native, low-code pattern for centralising CloudWatch Logs across accounts.

See more DOP-C02 practice questions, answers explained.

Exam traps in Monitoring and Logging

Answers that look right on this material and are not. Each one is a distractor from a different question in the DOP-C02 bank for this domain.

Schedule an hourly AWS Lambda function in each member account that calls the CloudWatch Logs export-to-S3 task, then copies the exported objects into the logging account and indexes them into OpenSearch from there.
Why it is wrong: The export task plus a scheduled Lambda can move logs, but exports run in batches on a schedule rather than continuously, so the near real-time requirement fails and the team still maintains custom copy and index code.
Build an Amazon Data Firehose stream in each account that pushes metrics and logs into a central Amazon S3 bucket, then query the consolidated data from the on-call account with Amazon Athena during incidents.
Why it is wrong: Firehose to a central bucket does consolidate the raw data, but it copies telemetry into a new store and forces an Athena query workflow rather than the live cross-account metric, log and trace search the team asked for, adding pipeline overhead.
In each source account, schedule a CreateExportTask that exports the log groups to an Amazon S3 bucket in the central account every hour for later loading into OpenSearch.
Why it is wrong: Scheduled export tasks move log data to S3 and seem to centralise it, but they run in batches on a timer and cannot deliver the near real-time stream the requirement demands.

Examworthy is not affiliated with or endorsed by Amazon Web Services. Original, blueprint-aligned practice material only.