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.

• ✓

  Attach a service control policy (SCP) to all accounts that denies s3:PutBucketEncryption or s3:PutObject without encryption.

  Why this is correct

  A service control policy (SCP) attached at the organization root or to all accounts is the only option that gives central, preventive enforcement across every member account. By explicitly denying s3:PutBucketEncryption and s3:PutObject when encryption is not specified (using conditions like s3:x-amz-server-side-encryption), the SCP blocks the API actions themselves before any resource policy or IAM evaluation, so no account or workload can bypass the requirement. This works even if a member account administrator has full administrative permissions, because SCPs act as a permission boundary for all IAM principals in the account.

• ✗

  Apply an S3 bucket policy on each account's buckets to deny unencrypted object uploads.

  Why it's wrong here

  While an S3 bucket policy with a Deny effect for s3:PutObject without encryption can protect a specific bucket, it must be manually attached to every bucket in every account. This approach does not scale across an organization: S3 bucket policies are resource-based and scoped to a single bucket, so there is no way to apply them centrally from AWS Organizations. Additionally, if a new bucket is created without the policy, it is immediately non-compliant, and the policy may be accidentally removed by bucket owners, making this a fragmented and error-prone control.

• ✗

  Create an IAM policy in the master account that denies S3:PutObject without encryption.

  Why it's wrong here

  IAM policies in the management (master) account are only effective for principals in that same account; they are never inherited by users, roles, or resources in member accounts of an AWS Organization. An IAM policy denying s3:PutObject without encryption would therefore have zero effect on workloads running in other accounts, which is the core requirement of the scenario. This misconception often arises because organization administrators think of the master account as a central control point, but IAM policies operate only within the account where they are created.

• ✗

  Use AWS Config rules to evaluate S3 bucket encryption and trigger a remediation action via AWS Systems Manager Automation.

  Why it's wrong here

  AWS Config rules that detect unencrypted S3 buckets or objects and trigger SSM Automation remediation are inherently reactive. They rely on periodic evaluations or configuration change notifications, meaning there is a window during which non-compliant resources exist and can be accessed. Furthermore, this approach does not block the initial write action; it only corrects the bucket or object after the fact, and remediation can fail due to permission issues or incorrect Automation documents, so it cannot guarantee that unencrypted data is never written.

Go deeper

Related to this question