SCS-C02 Infrastructure Security Practice Question

Network Topology

Refer to the exhibit. A security engineer runs the command above and sees that the flow log status is ACTIVE. However, the engineer notices that no logs are appearing in the CloudWatch log group. What is the most likely cause?

⚠ Common exam trap

Watch out — candidates often assume an ACTIVE status guarantees logs are being delivered, but AWS explicitly documents that ACTIVE only means the configuration is valid, not that delivery is succeeding; the real test is whether the IAM role has the correct permissions to write to CloudWatch Logs.

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

✓

The IAM role specified in DeliverLogsPermissionArn does not have permissions to PutLogEvents.

The most likely cause is that the IAM role specified in the DeliverLogsPermissionArn does not have the necessary permissions to call PutLogEvents on the CloudWatch Logs log group. Even if the flow log status is ACTIVE, the delivery of log records will silently fail if the role lacks the required logs:PutLogEvents, logs:CreateLogStream, and logs:DescribeLogStreams actions. The ACTIVE status only indicates that the flow log configuration is valid and the service is attempting to deliver logs, not that delivery is succeeding.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
The TrafficType is set to ALL, which captures too much data and causes throttling.
Why it's wrong here
TrafficType ALL is a valid, intended configuration for VPC Flow Logs and simply captures both accepted and rejected traffic. Flow log records are batched and pushed to CloudWatch as a single PutLogEvents call, so a high volume of records does not cause API throttling or dropped logs. If logs are missing, the fault lies in the delivery role or destination, not in the traffic filter setting.
✓
The IAM role specified in DeliverLogsPermissionArn does not have permissions to PutLogEvents.
Why this is correct
The DeliverLogsPermissionArn role must have a trust policy allowing vpc-flow-logs.amazonaws.com to assume it and an IAM permissions policy granting logs:CreateLogGroup, logs:CreateLogStream, and logs:PutLogEvents. Without logs:PutLogEvents, the Flow Logs service cannot append records to the CloudWatch log stream, so the flow log remains in a FAILED state. Adding the missing PutLogEvents permission is the standard fix for this symptom.
✗
The flow log is attached to an ENI instead of a subnet.
Why it's wrong here
Attaching a flow log to an ENI is fully supported; flow logs can be created at the VPC, subnet, or network interface level. The ENI attachment granularity does not disable or throttle delivery, and the service will publish records for that interface. Therefore, the attachment target cannot explain missing logs; you must inspect the IAM delivery role and the log group configuration instead.
✗
The flow log destination is set to CloudWatch Logs but the log group is encrypted with KMS.
Why it's wrong here
A KMS-encrypted CloudWatch Logs log group is a valid destination for VPC Flow Log delivery, because CloudWatch Logs transparently uses the configured key when writing log events. Encryption alone does not block PutLogEvents or alter flow log publication; at most, a restrictive key policy could deny the delivery role's kms:Encrypt/GenerateDataKey actions. Since the symptom is no logs, the missing PutLogEvents permission in the delivery role is the actionable root cause.

Go deeper

SCS-C02 Infrastructure Security Practice Question

Why each option matters

Option-by-option breakdown

Related to this question