SCS-C02 Infrastructure Security Practice Question

A company is using AWS CloudFormation to deploy infrastructure. Which method ensures that sensitive data, such as database passwords, is not exposed in the template or outputs?

⚠ Common exam trap

Candidates often confuse the 'NoEcho' property with a security control that protects the value from being exposed anywhere, when in reality it only hides the input during parameter entry and does not prevent exposure in the template file, outputs, or logs.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Use a dynamic reference to a Systems Manager Parameter Store parameter.

Using a dynamic reference to an AWS Systems Manager Parameter Store parameter allows CloudFormation to retrieve the password at stack creation time without embedding it in the template or exposing it in outputs. The password is stored securely in Parameter Store, and CloudFormation resolves the reference dynamically, ensuring the sensitive value never appears in plaintext in the template, stack events, or outputs.

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 the 'NoEcho' property on the password parameter.
Why it's wrong here
Setting NoEcho on a parameter only masks the value from stack operation logs and the console during review; it does not encrypt or protect the secret at rest. The plaintext password still exists in the CloudFormation template and can be viewed by anyone with read access to the template or stack metadata. This is not a secure way to handle secrets because the template itself remains a plaintext source of the credential.
✗
Store the password in the template outputs.
Why it's wrong here
CloudFormation outputs are returned after stack creation or update and are visible to anyone with DescribeStacks permission or access to the AWS Management Console. Outputs are stored and displayed in plaintext, and they may also be captured in CloudTrail logs or other monitoring tools. Exposing a password through outputs defeats the purpose of secret protection because it becomes trivially accessible to anyone who can query the stack details.
✗
Hardcode the password in the template and use the 'NoEcho' property.
Why it's wrong here
Hardcoding a password directly in the template, even with the NoEcho property, leaves the plaintext secret embedded in the template content itself. The template is often stored in version control, S3 buckets, or other systems with broader access, so the secret can be exposed through those channels. NoEcho only hides the value from operation logs and console display, not from anyone who reads the template file, making this practice fundamentally insecure.
✓
Use a dynamic reference to a Systems Manager Parameter Store parameter.
Why this is correct
A dynamic reference to Systems Manager Parameter Store, such as {{resolve:ssm:parameter-name}}, lets CloudFormation retrieve the password securely at deployment time without ever embedding it in the template. The parameter can be stored as a SecureString using AWS KMS encryption, and access can be governed by IAM policies, ensuring only authorized stacks and roles can retrieve the value. This approach separates secrets from infrastructure code, follows least-privilege principles, and provides auditability through Parameter Store and CloudTrail.

Visual reference

Go deeper

SCS-C02 Infrastructure Security Practice Question

Why each option matters

Option-by-option breakdown

Related to this question