DOP-C02 Configuration Management and IaC 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 the DeletionPolicy attribute to retain the bucket.

  Why it's wrong here

  The DeletionPolicy attribute is a stack-level lifecycle policy that determines the fate of the resource when the entire stack is deleted—Retain preserves the bucket after stack teardown, Snapshot captures its state, and Delete removes it. It operates on an already-created physical resource and has absolutely no influence over how CloudFormation names the bucket during initial creation. Bucket naming is driven solely by the BucketName property: if omitted, CloudFormation auto-generates a unique name, but DeletionPolicy never enters that decision. Therefore, this approach cannot prevent the naming conflict the developer is trying to solve.

• ✗

  Set the BucketName property to a unique value using a parameter.

  Why it's wrong here

  Setting BucketName to a parameter value delegates the uniqueness problem to the user—CloudFormation will not validate or alter the provided value, so the parameter must already be globally unique or the bucket creation fails with a BucketAlreadyExists or BucketAlreadyOwnedByYou error. Even if a parameter is used, the same value can be reused across different stacks or accounts, causing collisions, and it requires the developer to manually devise a naming scheme (e.g., appending random strings) rather than letting CloudFormation handle uniqueness automatically. This merely shifts the burden without providing any guarantee, making it no more robust than hardcoding a static name.

• ✗

  Use the UpdateReplacePolicy attribute to control replacement.

  Why it's wrong here

  The UpdateReplacePolicy attribute controls what happens to the original physical resource when CloudFormation must replace it during a stack update because of a property change that requires a new resource. It does not affect the naming of the bucket at creation time, nor does it influence the generation of unique identifiers. Its purpose is to dictate whether the old bucket is retained, snapshotted, or deleted when a replacement occurs—not to resolve naming collisions. Since the developer's scenario is about the initial creation of a bucket with a unique name, this update-time policy is entirely irrelevant.

• ✓

  Omit the BucketName property so CloudFormation generates a unique name.

  Why this is correct

  When the BucketName property is omitted from an S3 bucket resource, CloudFormation automatically generates a globally unique name by combining the stack name with a random suffix (e.g., my-stack-s3bucket-1a2b3c4d5e6f). This generated name guarantees uniqueness across all AWS accounts and regions, because the random component virtually eliminates collision risk. CloudFormation then exposes this generated name through the Ref function and the resource's physical ID, allowing other resources to reference it without ever needing to know the exact value beforehand. This is the simplest and most reliable way to avoid bucket-name conflicts without manual input.

Go deeper

Related to this question