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 a CloudFormation mapping to store the secret ARN.

  Why it's wrong here

  CloudFormation mappings are static key-value pairs defined directly in the template; they only provide lookups for constant values like AMI IDs or instance types. A mapping cannot invoke AWS Secrets Manager, and referencing a mapping with Fn::FindInMap returns the secret ARN as a literal string—not the secret value. If the resource property requires a password, this approach injects the ARN instead of the actual secret, causing authentication failures. The only native way to dereference a Secrets Manager secret is a dynamic reference or a custom resource.

• ✓

  Use a dynamic reference with '{{resolve:secretsmanager:secret-id:secret-string}}' in the template.

  Why this is correct

  The dynamic reference syntax {{resolve:secretsmanager:secret-id:secret-string}} is correct because CloudFormation resolves it to the actual secret value at stack creation or update time. The full syntax allows you to specify a JSON key, version stage, or version ID, giving you precise control over which secret value is injected into a resource property. CloudFormation calls GetSecretValue on your behalf, so the secret never appears in the template, change sets, or the rendered stack template. To use this, ensure the CloudFormation execution role has the secretsmanager:GetSecretValue permission for the target secret.

• ✗

  Hardcode the password in the template as a literal string.

  Why it's wrong here

  Hardcoding a password as a literal string in a CloudFormation template is a severe anti-pattern because the template is stored in an S3 bucket managed by CloudFormation, and any snapshot of the stack template via the console, API, or change sets will expose the plaintext secret. It prevents secret rotation, complicates auditing, and increases the risk of accidental disclosure through version control or copy-paste. AWS best practices require storing secrets in Secrets Manager and referencing them dynamically rather than embedding them as literals.

• ✗

  Use a CloudFormation parameter with a default value referencing the secret ARN.

  Why it's wrong here

  A CloudFormation parameter with a default value set to a secret ARN merely passes that ARN as a text string to the resource property; CloudFormation does not automatically dereference it via Secrets Manager. Parameter values are substituted literally during stack operations, so the resource would receive the ARN string (e.g., 'arn:aws:secretsmanager:...') as the password, which is almost certainly invalid. Furthermore, dynamic references require the {{resolve:...}} expression to be a literal in the template; you cannot build it from a parameter or use Fn::Sub to assemble it. To retrieve a secret from a parameter-supplied ARN, you would need a custom resource or Lambda-backed function.

Go deeper

Related to this question