SOA-C02 Monitoring, Logging, and Remediation Practice Question
A SysOps administrator is setting up centralized logging for multiple AWS accounts using CloudWatch Logs. Which TWO actions should the administrator take to ensure that logs from all accounts are aggregated in a single account?
⚠ Common exam trap
Test-takers frequently confuse IAM cross-account roles with CloudWatch Logs destinations, assuming that a role with PutLogEvents permissions is sufficient, when in fact CloudWatch Logs requires a destination resource policy for cross-account delivery.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
In the central account, create a CloudWatch Logs destination and attach a resource policy that grants the source accounts permission to write logs.
A CloudWatch Logs destination in the central account, combined with a resource policy that grants the source accounts permission to write logs, is the standard mechanism for cross-account log aggregation. The destination acts as a target for subscription filters, and the resource policy explicitly allows the source accounts to call the PutLogEvents API against that destination. This setup ensures that log events from source accounts are delivered to the central account without requiring IAM roles or additional infrastructure.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
In the central account, create an IAM role that trusts the source accounts and allows PutLogEvents.
Why it's wrong here
Cross-account CloudWatch Logs delivery does not rely on IAM roles that source accounts assume. The destination account attaches a resource-based policy to the CloudWatch Logs destination, granting the source accounts the cloudwatch:PutLogEvents permission directly. A role would require the source account to perform an unnecessary AssumeRole call, and subscription filters do not support role assumption for authentication. Thus, this option misidentifies the permission model for centralized logging.
- ✓
In the central account, create a CloudWatch Logs destination and attach a resource policy that grants the source accounts permission to write logs.
Why this is correct
This is the correct approach because a CloudWatch Logs destination is a logical target that can receive log events from other accounts. The central account must attach a resource-based policy to the destination, explicitly listing the source account IDs and allowing them to call PutLogEvents. This policy grants the necessary write access without requiring cross-account IAM roles or complex key management, enabling centralized aggregation of logs from multiple source accounts.
- ✓
In each source account, configure a subscription filter on the log groups to send log events to the central account's CloudWatch Logs destination.
Why this is correct
In each source account, the log group must have a subscription filter that forwards matching log events to the central destination ARN. You can use an empty filter pattern to send all events, and the filter invokes the CloudWatch Logs destination permission to deliver data. This is the required client-side configuration that completes the cross-account logging pipeline, because the destination alone does not pull logs; each source must actively push them.
- ✗
In the central account, create a log group with the same name as the source accounts' log groups.
Why it's wrong here
Creating a log group in the central account with the same name as the source accounts' log groups is not necessary nor part of the setup. CloudWatch Logs destinations route incoming events to the underlying target (such as a Kinesis stream or Lambda function) and do not correlate names with source log groups. The destination's log stream naming is independent, so identical log group names do not affect delivery and providing them adds no value.
- ✗
In each source account, create a Kinesis Data Firehose delivery stream that sends logs to the central account's S3 bucket.
Why it's wrong here
Kinesis Data Firehose delivery streams are not a supported direct destination for CloudWatch Logs subscription filters, which only support Kinesis Data Streams and Lambda as targets. To get logs to S3, you would need a central destination such as a Kinesis stream or Lambda, and then optionally a Firehose in the central account. Creating a Firehose in each source account is an incorrect and overly complex pattern, and it bypasses the destination resource policy model used for cross-account delivery.
Go deeper
Related to this question
About these practice questions
Courseiva writes every SOA-C02 question from scratch — 1,169 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This SOA-C02 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SOA-C02 exam.