How do you stream CloudWatch Logs cross-account to Kinesis Data Streams?
A company has a production AWS account that runs company workloads. The company's security team created a security AWS account to store and analyze security logs from the production AWS account. The security logs in the production AWS account are stored in Amazon CloudWatch Logs. The company needs to use Amazon Kinesis Data Streams to deliver the security logs to the security AWS account. Which solution will meet these requirements?
Community Votes
100% of anonymous learners picked answer D. Votes are pick records left by other test-takers — they are not the verified answer.
Community Insight
This question tests cross-account CloudWatch Logs subscription architecture; the trap is placing the Kinesis destination stream or the subscription filter in the wrong AWS account.
Delivering CloudWatch Logs from a production account to a security account with Kinesis Data Streams requires the destination stream in the security account and the subscription filter in the production account. This page confirms option D and explains the cross-account trust-policy and resource-placement requirements.
The most common wrong answer is A: it puts the destination Kinesis stream in the production account and gives the security account cross-account Kinesis permissions, which sends logs toward the wrong account and leaves no production subscription filter.
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
Option D puts the destination Kinesis data stream in the security AWS account, which is where the company wants to store and analyze the logs, and creates the CloudWatch Logs subscription filter in the production account where the log groups live. For cross-account delivery, CloudWatch Logs must be able to assume a role whose trust policy allows the CloudWatch Logs service principal to call Kinesis PutRecord or PutRecords on the destination stream. That role and trust policy bridge the accounts without moving the stream into production. As Christina666 noted, "Kinesis Data Streams in the security account ensures the logs reside" in the designated security environment. The subscription filter in production then selects the log groups and sends matching events to the security-account stream.Why the Other Options Are Wrong
Option A reverses the required data flow: it creates the destination stream in production and tries to give the security account a role into Kinesis there, so the security account is not the destination owner and CloudWatch Logs in production has no proper subscription mechanism. Option B correctly places the stream in the security account but puts the subscription filter in the security account, while the CloudWatch log groups being filtered are in production. Option C is wrong on both resource placement and direction: the destination stream belongs in the security account, not production, and a production-account role granted cross-account Kinesis access in the security account does not make the security account the recipient of the logs. The common theme is that the subscription filter must be in the sending account and the Kinesis destination in the receiving account.Community Comment Notes
Salam9 linked the AWS account-level subscription filter example for sending CloudWatch Logs to Kinesis, which matches the D pattern. GiorgioGss shared the CrossAccountSubscriptions-Kinesis documentation page, reinforcing that cross-account delivery uses a destination stream in the receiving account and a subscription filter in the source account. Christina666 summarized the flow as "Cross-Account Delivery: Kinesis Data Streams in the security account" plus filtering controls in production. Aesthet stated that both ChatGPT and they agreed with answer D, and that consensus aligns with the AWS service model rather than the vote count alone.Official Reference
- https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/SubscriptionFilters-AccountLevel.html#DestinationKinesisExample-AccountLevel
- https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CrossAccountSubscriptions-Kinesis.html
- https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html
Exam Strategy
For cross-account CloudWatch Logs to Kinesis, map each resource to its owner: destination stream in the receiving account, subscription filter in the sending account, and a trust policy that lets CloudWatch Logs assume the role and put records. Eliminate options that put the stream in the production account or the filter in the security account.
Frequently Asked Questions
Why must the Kinesis data stream be in the security account instead of production?
The destination stream must live where the logs are stored and analyzed—the security account—while production only sends records through its subscription filter and assumed role.
Why is a subscription filter in the security account wrong for option B?
CloudWatch Logs subscription filters must be created in the account that owns the log group—production—because that is where the logs are selected and sent to the cross-account Kinesis destination.
Related Analysis
Practice All DEA-C01 Questions
Access 100 questions with complete answers and detailed explanations.
View Full DEA-C01 Practice Test →