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 CloudFormation parameter with a default value and use the Ref intrinsic function.

  Why it's wrong here

  CloudFormation parameters are visible in plaintext in the template and in the stack's parameter list in the Management Console. Using the Ref intrinsic function simply substitutes the value during stack creation, leaving the actual password exposed to anyone with read access to the stack or template. Parameter values may also appear in CloudTrail logs, further compromising the secret, and this approach provides no encryption, rotation, or fine-grained access control.

• ✗

  Generate a password manually and store it in a text file in Amazon S3; reference the S3 URL in the template.

  Why it's wrong here

  Storing a manually generated password in a text file in Amazon S3 and referencing the S3 URL exposes the secret as plaintext in the object and reveals the bucket/object name in the template. CloudFormation does not natively fetch the file content from the URL, so you would need a custom resource or user-data script to retrieve it, increasing complexity. If the bucket is misconfigured or the object is publicly accessible, the password is immediately compromised, and because the password is manually generated, it cannot be automatically rotated.

• ✓

  Use AWS Secrets Manager to generate a random password and reference it in the CloudFormation template using a dynamic reference (resolve:secretsmanager).

  Why this is correct

  Using AWS Secrets Manager with a dynamic reference allows CloudFormation to retrieve a secret at deployment time without exposing the value in the template, console, or logs. An AWS::SecretsManager::Secret resource with GenerateSecretString can automatically create a random password, and the rest of the stack can reference it via {{resolve:secretsmanager:secret-id:SecretString}}. This approach integrates with IAM policies, supports fine-grained permissioning, and can enable automatic rotation via a Lambda function, making it the AWS recommended best practice for secrets in infrastructure as code.

• ✗

  Use AWS Systems Manager Parameter Store (String type) and reference it with the dynamic reference resolve:ssm.

  Why it's wrong here

  The Systems Manager Parameter Store String type stores the password as plaintext, whereas SecureString would use KMS to encrypt it. The dynamic reference resolve:ssm can read the parameter during stack deployment, but it does not mitigate the fact that the underlying value is visible to anyone with access to Parameter Store. Additionally, String parameters do not support automatic password generation or rotation. For secrets referenced in CloudFormation, Secrets Manager's dedicated secret management capabilities—such as native rotation and secret generation—make it the more secure and complete choice.

Go deeper

Related to this question