SCS-C02 Infrastructure Security Practice Question

Network Topology

Refer to the exhibit. A security engineer runs the CLI command and receives the output shown. The engineer expects to see flow logs for a specific subnet, but the output shows the resource ID as a VPC. What is the most likely reason?

⚠ Common exam trap

Test-takers frequently assume the flow log is misconfigured due to permissions or delivery settings, when the real issue is the scope at which the flow log was created—a common confusion between VPC-level and subnet-level flow 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 flow log was created at the VPC level, not at the subnet level.

The output shows the resource ID as a VPC (vpc-xxxx), but the security engineer expected to see flow logs for a specific subnet. This indicates that the flow log was created at the VPC level, not at the subnet level. In AWS, VPC Flow Logs can be created at the VPC, subnet, or network interface level, and the resource ID in the flow log output reflects the level at which the log was configured. Since the engineer expected subnet-level logs, the most likely reason is that the flow log was created for the entire VPC instead of the specific subnet.

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 flow log is not active; it shows ACTIVE, so that's not the issue.
Why it's wrong here
The flow log's status is shown as ACTIVE, which means it is successfully capturing traffic for its attached resource. The problem is not that the flow log is inactive; rather, it is scoped to a different resource than the subnet being examined. Since the status is healthy, the root cause must lie in the flow log's resource scope, not its operational state.
✗
The flow log is configured to deliver to CloudWatch, but the log group name is incorrect.
Why it's wrong here
The CLI output displays the CloudWatch Logs destination along with the log group name, and that log group matches the filter pattern used in the query. The flow log is correctly configured to send logs to that log group, so the log group name is not the issue. The real issue is that the flow log is attached to the VPC, not to the subnet, so no subnet-specific logs are being generated.
✗
The IAM role does not have permissions to deliver logs for subnets.
Why it's wrong here
The IAM role listed in the flow log configuration is the same role used for VPC flow log delivery, and that role already has the required permissions to publish to CloudWatch Logs. For subnet flow logs, the identical IAM role is acceptable because the delivery mechanism and permissions are at the VPC level and apply equally to subnet-level flow logs. Therefore, IAM permissions are not the cause of the missing subnet logs.
✓
The flow log was created at the VPC level, not at the subnet level.
Why this is correct
The resource ID in the flow log output is prefixed with "vpc-", which indicates the flow log was created at the VPC level rather than at the subnet level. As a result, the flow log captures all traffic in the VPC, and the query is not filtering for the specific subnet due to the resource scope. To see subnet-specific flow logs, you must create a separate flow log with the subnet ID as the resource ID.

Visual reference

Go deeper

SCS-C02 Infrastructure Security Practice Question

Why each option matters

Option-by-option breakdown

Related to this question