SOA-C02 Deployment, Provisioning, and 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.

• ✗

  Store the password as a plaintext parameter in the CloudFormation template and mark it as NoEcho.

  Why it's wrong here

  The NoEcho attribute only masks the parameter value in CloudFormation console output and API calls; it does not encrypt the value, and the plaintext password still resides in your stack template or parameters file. CloudFormation does not provide any secret storage, so the credential is recoverable from the template itself and cannot be rotated. This leaves the database password static and exposed to anyone with read access to the template source.

• ✗

  Use AWS Systems Manager Parameter Store to store the password as a SecureString and reference it using the dynamic reference {{resolve:ssm-secure:password}} in the template.

  Why it's wrong here

  Parameter Store SecureString does use AWS KMS encryption and the {{resolve:ssm-secure:password}} dynamic reference works in CloudFormation. However, Parameter Store does not offer native automatic rotation for secrets; you would have to write a custom Lambda function to rotate both the database and the parameter value on a schedule. Without that custom work, the password remains a long-lived static secret, which is why this does not satisfy the rotation requirement.

• ✓

  Use AWS Secrets Manager to store the password and reference it using the dynamic reference {{resolve:secretsmanager:secretId:secretString:password}} in the CloudFormation template. Enable automatic rotation.

  Why this is correct

  Secrets Manager is a purpose-built secret management service with managed automatic rotation via a configurable Lambda rotation function, so the database password is rotated on a schedule without custom code. The dynamic reference {{resolve:secretsmanager:secretId:secretString:password}} fetches the current secret value at CloudFormation stack creation/update time without ever putting the password in the template. This combines secure storage, seamless retrieval, and automated rotation, making it the correct choice.

• ✗

  Hardcode the password in a userdata script that is passed to the EC2 instances.

  Why it's wrong here

  Hardcoding a password in a UserData script is insecure because the script is stored as plaintext in the EC2 instance's user data metadata and can be viewed by any user with ec2:DescribeInstanceAttribute permissions. It also ends up in the launch template or instance details and never supports automatic rotation, so the credential is static and recoverable. This violates security best practices because credentials should never be embedded in instance configuration.

Go deeper

Related to this question