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.

• ✓

  Use an SCP to deny s3:PutBucketEncryption with encryption disabled, and AWS Config rules to detect non-compliant buckets.

  Why this is correct

  An SCP at the root or OU level is the correct proactive control because it allows you to explicitly deny the s3:PutBucketEncryption API action when the encryption configuration is null or set to SSE-S3, effectively preventing any IAM principal from creating or modifying a bucket without server-side encryption. This works on all accounts in the organization, regardless of local IAM configurations, and blocks the disabling of encryption even after the bucket is created. AWS Config then acts as a detective layer: the managed rule s3-bucket-encryption-enabled continuously evaluates buckets and flags any that are non-compliant, including those that existed before the SCP was applied, ensuring full coverage through a defense-in-depth approach.

• ✗

  Attach an IAM policy to all users denying s3:PutObject without KMS.

  Why it's wrong here

  This approach is insufficient because it narrowly targets object uploads (s3:PutObject) rather than the bucket-level encryption configuration itself. An IAM policy attached to users does not affect the s3:CreateBucket or s3:PutBucketEncryption actions, and S3's default encryption at the bucket level determines whether unencrypted objects are accepted—so the bucket could still be created with SSE-S3 disabled, allowing non-compliant uploads by roles, services, or root unless the same policy is applied everywhere. Moreover, user-attached IAM policies are bypassable if an adversary gains access to a role or performs actions via a service that does not carry the policy, making this a fragmented and incomplete safeguard rather than a centralized control.

• ✗

  Use an SCP to deny s3:CreateBucket without encryption, and rely on CloudTrail to alert.

  Why it's wrong here

  The s3:CreateBucket API action does not include an 'encryption' parameter, so an SCP cannot conditionally deny bucket creation based on encryption status—there is no such condition key available for that action. Consequently, the SCP would either block all bucket creation or fail to stop unencrypted buckets, depending on how it is written, making it technically invalid. Additionally, CloudTrail only logs API activity; it cannot detect pre-existing non-compliant resources, and relying on alerting alone lacks automated remediation, leaving non-compliant buckets invisible until a human reviews the logs, which is neither proactive nor reliable for continuous compliance.

• ✗

  Use AWS Config rules only, with automatic remediation via Lambda.

  Why it's wrong here

  AWS Config is a detective control that identifies non-compliant resources after they exist, so an unencrypted S3 bucket is still created and accessible until the rule detects it and Lambda remediation runs—creating a window of exposure and potential compliance violation. Automatic remediation via Lambda is also complex because you must differentiate between buckets that need SSE-S3 versus KMS, handle buckets with existing object-versions, and manage error-prone steps like setting default encryption after objects have been uploaded unencrypted (which does not retroactively encrypt them). While Config plus Lambda adds value, it lacks the preventive guarantee that a well-designed SCP provides, since the SCP blocks the non-compliant API call at the boundary before any resource exists.

Go deeper

Related to this question