DOP-C02 SDLC Automation 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.

• ✗

  !Ref 'AWS::StackName'

  Why it's wrong here

  The AWS::StackName pseudo parameter is simply the user-defined name of the CloudFormation stack, which is not guaranteed to be unique across accounts, regions, or even over time as stacks are deleted and recreated. Because S3 bucket names live in a global namespace, relying on stack name alone would easily lead to collisions with buckets created by other stacks in other accounts. Additionally, stack names can contain characters invalid in S3 bucket names, so using it directly is neither safe nor valid.

• ✗

  !GetAtt S3Bucket.Arn

  Why it's wrong here

  The !GetAtt S3Bucket.Arn function returns an attribute of an existing resource, which is resolved only after the bucket has been successfully created. When defining the BucketName property of the same bucket, the ARN is not yet available during template evaluation, creating a circular dependency that CloudFormation cannot resolve. Moreover, the ARN itself contains the bucket name, so it cannot be used as the input to define that same name—this makes the approach fundamentally impossible.

• ✓

  !Sub 'mybucket-${AWS::AccountId}'

  Why this is correct

  AWS::AccountId is a true pseudo parameter that is resolved during template evaluation, providing a unique, numeric identifier for the current AWS account. When combined with a fixed prefix like 'mybucket-', the resulting bucket name is globally unique across all accounts and regions because each account has a distinct ID, satisfying S3's global namespace requirement. This approach is deterministic, readable, and avoids the circular dependency issues of resource attributes, making it a widely adopted best practice for naming resources.

• ✗

  !Select [0, !Split ['-', !Ref 'AWS::Region']]

  Why it's wrong here

  This expression extracts only the first segment of the region name, such as 'us' from 'us-east-1', which is an extremely coarse grouping and not remotely unique—countless buckets would share the same name when using this logic. Even the full region name alone would not be globally unique across accounts, but this truncated version fails even faster. Since S3 bucket names must be unique worldwide, this option cannot possibly guarantee the required uniqueness for the bucket name.

Go deeper

Related to this question