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.

• ✗

  S3 Object Lock

  Why it's wrong here

  S3 Object Lock is designed for write-once-read-many (WORM) governance, using retention modes (Governance and Compliance) and legal holds to prevent objects from being deleted or overwritten. It does not address data at rest encryption, which protects the confidentiality of object data through keys managed via SSE-S3, SSE-KMS, or SSE-C. Enabling Object Lock on a bucket has no effect on whether objects are stored encrypted; encryption must be configured separately through default encryption or object upload headers.

• ✗

  Bucket policy with a Deny for unencrypted uploads

  Why it's wrong here

  A bucket policy with a Deny statement can reject uploads that do not include encryption headers, such as requiring `x-amz-server-side-encryption:AES256` or a KMS key ARN. This is a preventive control that enforces client-side behavior, but it does not automatically modify the object during upload or encrypt existing objects. The policy condition only evaluates the request parameters; if an upload is allowed without encryption (e.g., because the Deny scope is incomplete), the object remains plaintext. For automatic encryption without relying on clients, S3 bucket default encryption is the appropriate mechanism.

• ✗

  S3 Versioning

  Why it's wrong here

  S3 Versioning maintains multiple versions of an object, enabling rollback against accidental overwrites or deletions and supporting lifecycle or retention scenarios. It is a data management feature that does not change how object data is protected at rest; each version can have its own encryption status, and unencrypted versions remain unencrypted indefinitely. Enabling versioning cannot ensure that new objects are encrypted, nor does it provide any key management. Encryption is orthogonal to versioning and must be configured via default encryption or per-object headers.

• ✓

  Default encryption

  Why this is correct

  Default encryption is a bucket-level setting that automatically applies server-side encryption (SSE-S3 or SSE-KMS) to all new objects, even when the upload request does not include encryption headers. When enabled, every PUT that does not explicitly specify an encryption method is wrapped with the bucket's configured encryption, thereby ensuring new objects are encrypted at rest. Note that default encryption only affects objects uploaded after the setting is enabled; existing objects require rewriting or a copy operation to be encrypted. It is the only option that actively encrypts data without relying on client behavior.

Go deeper

Related to this question