DOP-C02 Security and Compliance Practice Question

Answer analysis

Option-by-option breakdown

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

• ✗

  Enable VPC Flow Logs in each VPC and aggregate them in Amazon CloudWatch Logs

  Why it's wrong here

  VPC Flow Logs capture IP traffic metadata—source/destination addresses, ports, protocol, and packet/byte counts—not the IAM user, role, or API action that created or modified a security group. Since the audit requirement is to attribute every security group change to a specific principal and operation, flow logs are the wrong data source; also, aggregating them in CloudWatch Logs does not add an immutable audit trail, and logs can be modified or deleted by users with sufficient permissions.

• ✓

  Enable AWS CloudTrail in all accounts, deliver logs to a central S3 bucket with S3 Object Lock enabled

  Why this is correct

  CloudTrail is the only service that records management-plane API events such as AuthorizeSecurityGroupIngress, RevokeSecurityGroupEgress, and CreateSecurityGroup, including the requesting IAM principal, source IP, and request parameters. Delivering those trail logs to a centralized S3 bucket with S3 Object Lock enabled in compliance mode makes each log object write-once-read-many (WORM), preventing any user—even one with administrative privileges—from altering or deleting audit evidence, which satisfies the immutability and centralized audit requirements. Additionally, enabling CloudTrail in all accounts with a single organization trail and delivering to a central bucket provides a complete, tamper-proof, cross-account audit record of every security group change.

• ✗

  Enable Amazon GuardDuty and send findings to a central S3 bucket

  Why it's wrong here

  GuardDuty is a threat-detection service that analyzes VPC Flow Logs, DNS logs, and CloudTrail management events for suspicious activity such as crypto-mining, unauthorized port scanning, or compromised credentials; it does not purpose-built record or log every API call for auditing. While GuardDuty can detect some security group modifications as part of a broader threat scenario, it is not a complete audit trail of all changes, and sending findings to an S3 bucket simply stores alerts rather than the underlying change history, so it fails to meet the need for a full, immutable audit of every security group mutation.

• ✗

  Enable AWS Config rules to detect security group changes and store results in a central S3 bucket

  Why it's wrong here

  AWS Config records configuration state changes and can trigger rules to detect whether a security group was changed, but it captures the new configuration and the resource's compliance state—not the API caller, the IAM identity, or the exact action that caused the change. Although you could export Config snapshots or delivery history to S3, those snapshots are mutable and lack the principal-level detail required for auditing who made each change; also Config does not provide immutability, so an admin could overwrite or delete delivery files. Thus Config shows that a change happened, but not who did it, making it insufficient for a complete audit trail.

Go deeper

Related to this question