Courseiva

SOA-C02 Deployment, Provisioning, and Automation Practice Question

A SysOps administrator uses AWS CloudFormation to deploy infrastructure. The administrator needs to store and reference sensitive data such as database passwords in the stack without hardcoding them in the template. Which CloudFormation feature should be used?

⚠ Common exam trap

Many exam-takers confuse `NoEcho` (which only hides display output) with actual secure storage, or they assume static references work with Secrets Manager when only dynamic references are supported for both Parameter Store secure strings and Secrets Manager secrets.

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 AWS Systems Manager Parameter Store secure strings and dynamic references in the CloudFormation template

AWS CloudFormation supports dynamic references (using the `resolve:ssm` or `resolve:ssm-secure` syntax) that allow you to reference Systems Manager Parameter Store secure strings directly in the template. This keeps sensitive data like database passwords out of the template and the stack's metadata, ensuring they are not exposed in plaintext during stack operations or in the console.

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 Systems Manager Parameter Store secure strings and dynamic references in the CloudFormation template

    Why this is correct

    CloudFormation dynamic references (e.g., {{resolve:ssm-secure:MyParameter}}) resolve secure string parameter values from Systems Manager Parameter Store during stack create and update operations, so the plaintext secret never appears in the template itself. The secure string is encrypted with a customer-managed or AWS-managed KMS key, and CloudFormation retrieves the decrypted value only at stack operation time, which prevents secrets from being exposed in template files, repository history, or AWS CloudTrail logs.

  • ✗

    Use AWS Secrets Manager and reference the secret using a static reference in the template

    Why it's wrong here

    While AWS Secrets Manager is a valid service for storing credentials, CloudFormation does not support referencing a secret via a 'static reference' — a static reference would require the literal secret value to be embedded in the template or parameter file, defeating the purpose of a secret store. CloudFormation's native integration requires a dynamic reference in the format {{resolve:secretsmanager:secret-id:SecretString:password}} for Secrets Manager, just as it does for Parameter Store, so specifying a 'static reference' is technically incorrect and insecure.

  • ✗

    Define plaintext parameters in the template and mark them as NoEcho

    Why it's wrong here

    NoEcho only masks the value in CloudFormation console and API responses (such as DescribeStackEvents), but the plaintext parameter value remains literally defined in the template body and is not encrypted at rest. The template may be stored in S3, versioned in a code repository, or shared with others who need access to the template, exposing the secret to anyone who can read that template. NoEcho is not a security boundary and does not use any AWS KMS encryption, unlike dynamic references that resolve secure strings from Parameter Store.

  • ✗

    Store the secrets in an encrypted S3 object and reference it via a URL in the template

    Why it's wrong here

    Referencing an S3 URL provides a path to the data but does not integrate with CloudFormation's native dynamic referencing mechanism for automated secret retrieval. This method requires manual logic within the template to fetch and decrypt the object, whereas AWS Secrets Manager or Parameter Store allow direct integration through intrinsic functions. Storing files in S3 is appropriate for managing large configuration datasets or static assets that require versioned access rather than secure, programmatic credential injection.

Visual reference

Client Recursive Resolver Root DNS (13 root servers) TLD DNS (.com, .org, …) Authoritative example.com query IP addr answer

About these practice questions

One of 1,169 original SOA-C02 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

JA

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

This SOA-C02 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SOA-C02 exam.