SCS-C02 Threat Detection and Incident Response Practice Question
A company uses AWS Organizations with multiple accounts. The security team wants to centrally collect and analyze VPC Flow Logs from all accounts. The team has set up a central logging account with an S3 bucket that has a bucket policy allowing cross-account writes. However, VPC Flow Logs from member accounts are not appearing. What is the most likely cause?
⚠ Common exam trap
A common mix-up: candidates assume a properly configured bucket policy with cross-account permissions is sufficient, but AWS explicitly restricts VPC Flow Logs to same-account S3 destinations, making the policy irrelevant for direct 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
✓
VPC Flow Logs cannot be published directly to an S3 bucket in a different account. The logs must be published to a bucket in the same account as the VPC, and then replicated to the central account.
VPC Flow Logs cannot be published directly to an S3 bucket in a different AWS account. The destination S3 bucket must reside in the same account as the VPC from which the logs are generated. To centralize logs, you must first publish them to a bucket in the same account as the VPC, then use S3 cross-region replication or a similar mechanism to copy them to the central logging account. This is a fundamental limitation of the VPC Flow Logs service.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
AWS CloudTrail is not enabled in the member accounts.
Why it's wrong here
CloudTrail is a service that records API calls for auditing and governance, but VPC Flow Logs capture IP traffic information independently and do not require CloudTrail to be enabled. The flow log feature has no dependency on CloudTrail; it uses the VPC's own delivery mechanism to send logs to CloudWatch Logs or S3. Therefore, missing CloudTrail in member accounts is irrelevant to why flow logs are not arriving in the central S3 bucket.
- ✗
The VPC Flow Logs must be delivered to CloudWatch Logs first, then exported to S3.
Why it's wrong here
VPC Flow Logs can be published directly to an S3 bucket at creation time, so there is no mandatory requirement to first deliver to CloudWatch Logs and then export to S3. Although exporting from CloudWatch Logs is one possible approach, it is not a prerequisite for the default flow log functionality. The actual problem is the cross-account destination, not the delivery pipeline; the flow log would be delivered successfully to a same-account S3 bucket without any CloudWatch intermediary.
- ✓
VPC Flow Logs cannot be published directly to an S3 bucket in a different account. The logs must be published to a bucket in the same account as the VPC, and then replicated to the central account.
Why this is correct
When you create a VPC Flow Log, the destination S3 bucket must be in the same AWS account as the VPC; Amazon VPC does not support publishing flow logs directly to an S3 bucket in a different account. To aggregate logs from member accounts into a central account, you must first deliver them to an S3 bucket in each member account, then configure S3 replication or another copy mechanism to move the logs to the central bucket. Because the company attempted direct cross-account delivery, the flow logs fail to appear in the central destination.
- ✗
The S3 bucket policy does not allow the s3:PutObject action for the member accounts.
Why it's wrong here
The S3 bucket policy may indeed allow s3:PutObject from member accounts, but the flow log delivery request never reaches the bucket policy because the VPC Flow Logs service does not support cross-account S3 destinations. If the policy were misconfigured, you would typically see an error about access denial, yet the root cause here is a service limitation. Even with a perfectly permissive bucket policy, direct cross-account flow log publishing remains unsupported.
Quick reference
AWS S3 Storage Class Comparison
| Storage Class | Min Duration | Retrieval | Use Case |
|---|---|---|---|
| S3 Standard | None | Immediate | Frequently accessed data |
| S3 Standard-IA | 30 days | Immediate | Infrequent access, rapid retrieval |
| S3 One Zone-IA | 30 days | Immediate | Non-critical infrequent data |
| S3 Intelligent-Tiering | None | Immediate–hours | Unknown or changing access patterns |
| S3 Glacier Instant | 90 days | Milliseconds | Archive with instant retrieval |
| S3 Glacier Flexible | 90 days | Minutes–hours | Archive, flexible retrieval |
| S3 Glacier Deep Archive | 180 days | Hours | Long-term compliance archive |
Go deeper
Related to this question
About these practice questions
This SCS-C02 question is part of Courseiva's 1,205-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam 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 SCS-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 SCS-C02 exam.