DOP-C02 Resilient Cloud Solutions 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 MFA Delete and set a lifecycle policy to transition to S3 Glacier after 30 days.

  Why it's wrong here

  Enabling MFA Delete requires every permanently destructive operation (such as deleting an object version or suspending versioning) to be authenticated with a second factor, but it does not prevent an authorized user from deleting the current version of an object—it only adds an extra authentication step, which is impractical to automate and does not provide a retention guarantee. Additionally, transitioning to S3 Glacier (Standard) after 30 days does nothing to protect the object from being deleted during that 30-day window or even after the transition, since lifecycle policies only move data between storage classes and never grant immutability.

• ✗

  Enable versioning and set a lifecycle policy to expire noncurrent versions after 365 days.

  Why it's wrong here

  Versioning preserves every object version, but the protection is only against overwriting the current version; a user with Versioned Delete permission can still permanently delete both the current and all noncurrent versions. The lifecycle rule that expires noncurrent versions after 365 days automates cleanup of old versions but does not in any way protect the current version, which remains fully deletable at any time. Moreover, if a delete marker is created, the object is effectively 'deleted' even though the underlying version remains until lifecycle expiry, so versioning alone cannot stop a malicious actor from removing the live copy of your backup data.

• ✗

  Enable cross-Region replication to a bucket with versioning enabled.

  Why it's wrong here

  Cross-Region Replication (CRR) asynchronously copies objects to a destination bucket, but the source bucket remains a standard, mutable S3 bucket—any user with s3:DeleteObject permission can delete the object from the source, and with versioned bucket configuration also delete or add delete markers to versions. The destination bucket, even if versioning is enabled, is still an ordinary bucket; a user with permissions there can permanently purge both source-replicated copies and any version history. Finally, CRR does not apply any retention or governance controls, so it offers no protection against accidental, malicious, or ransomware-based deletion—it is simply a data availability feature, not a data protection feature.

• ✓

  Enable S3 Object Lock with Governance mode and a retention period of 365 days, and set a lifecycle policy to transition to S3 Glacier Deep Archive after 30 days.

  Why this is correct

  S3 Object Lock with Governance mode applies a Write-Once-Read-Many (WORM) policy that guarantees the backup objects cannot be modified or deleted by any ordinary user—even an account administrator with full S3 access—until the 365-day retention period expires. Governance mode does allow users with the s3:BypassGovernanceRetention permission to override the lock if needed, but a typical backup scenario doesn't grant that to regular IAM roles, so the data remains immutable for the entire year. Pairing this with a lifecycle rule that transitions the objects to S3 Glacier Deep Archive after 30 days satisfies both the need for protection and cost efficiency: the transition preserves Object Lock metadata and the object stays protected through the transition, after which Storage Costs drop to the lowest tier while retention still applies for the remaining 335 days.

Go deeper

Related to this question