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 AWS CloudFormation parameters with the NoEcho property set to true.

  Why this is correct

  Using the NoEcho property on a CloudFormation parameter is a valid best practice because it masks the parameter's value from the AWS Management Console, API responses, and stack outputs, preventing casual exposure during template operations. However, it does not encrypt the value or prevent the resource that receives the parameter from exposing it, so it should be combined with external secret stores. NoEcho is appropriate when a secret must be passed as a stack parameter, but the secret itself should never be embedded in the template or committed to version control.

• ✓

  Use AWS Systems Manager Parameter Store secure string parameters with dynamic references.

  Why this is correct

  Using AWS Systems Manager Parameter Store secure string parameters with dynamic references is a best practice because the secret is encrypted at rest with AWS KMS and referenced from CloudFormation via expressions like {{resolve:ssm-secure:parameter-name}}. This keeps the secret out of the template entirely, and IAM policies can control exactly which roles or stacks may retrieve the value. Parameter Store also offers versioning and integration with CloudWatch Events for auditing, making it suitable for configuration-like secrets such as API keys or non-rotating credentials.

• ✓

  Use AWS Secrets Manager dynamic references to retrieve secrets at deployment time.

  Why this is correct

  Using AWS Secrets Manager dynamic references in CloudFormation is a best practice because it retrieves the secret value at deployment time using syntax like {{resolve:secretsmanager:secret-id:SecretString:json-key:version-stage}}, so the plaintext secret never appears in the template. Secrets Manager adds purpose-built features like automatic rotation, fine-grained resource policies, and detailed audit logs, which are essential for credentials that must change frequently, such as database passwords. This approach decouples secret lifecycle management from infrastructure deployment.

• ✗

  Encrypt the CloudFormation template file with AWS KMS.

  Why it's wrong here

  Encrypting the CloudFormation template file with AWS KMS is not a valid best practice for secret management because the secret is still embedded in plaintext within the template. While KMS encryption protects the file at rest, the template must be decrypted during deployment, and the decrypted content can appear in CloudFormation API calls, CloudTrail logs, or the console if a decrypted copy is retrieved. Moreover, KMS encryption of the template does not address the root risk of secrets being duplicated in the infrastructure definition; it only masks a symptom.

• ✗

  Store secrets as plaintext in the template parameters.

  Why it's wrong here

  Storing secrets as plaintext in template parameters is unequivocally insecure because the actual secret value is visible in the CloudFormation template, in the stack parameter values returned by describe-stacks, and in CloudTrail logs of CreateStack and UpdateStack calls. This exposes the secret to any user with cloudformation:DescribeStacks permission and violates the principle of separating secrets from configuration. It also makes it impossible to rotate secrets without updating the stack, and the secret can be persisted in version control if the template is stored in a repository.

Go deeper

Related to this question