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.

• ✗

  Hardcode the password in the template and use a condition to only apply it in production.

  Why it's wrong here

  Hardcoding a password directly into a CloudFormation template—even behind a condition that limits it to production—is fundamentally insecure because the plaintext secret is embedded in the template file itself. Anyone with read access to the template, version control history, or an S3 bucket where the template is stored can extract the credential without triggering any CloudFormation security controls. Conditions only control deployment scope; they do not protect the template's contents, and CloudFormation does not redact or mask strings that appear literally in resource properties. This approach violates the principle of least privilege and the AWS Well-Architected security pillar, which mandate that secrets be managed by dedicated services like Secrets Manager.

• ✓

  Use a CloudFormation parameter with the NoEcho property set to true.

  Why this is correct

  A CloudFormation parameter with the NoEcho property set to true is a valid way to pass a password because the value is supplied at stack creation or update time—either via the console, CLI, or API—and is never displayed in the AWS Management Console, returned by DescribeStackResources, or emitted in CloudFormation event logs. However, you must still reference the parameter in the template resource properties so that the actual secret value is used during provisioning, and the secret remains visible to anyone with permission to view the resulting resource configurations (e.g., EC2 instance metadata if you pass it to user data). NoEcho only prevents the value from being echoed back in API responses; it does not encrypt the template or the secret at rest, so you must also ensure IAM policies restrict access to the stack's parameters. This is the simplest built-in mechanism for basic secret handling, but for more robust secret rotation and management, a dynamic reference or service like Secrets Manager is preferred.

• ✗

  Store the password in AWS Systems Manager Parameter Store and reference it with {{resolve:ssm:...}}

  Why it's wrong here

  Storing the password in Systems Manager Parameter Store and referencing it with {{resolve:ssm:...}} does pull the value at deployment time, but this syntax only works with plaintext or String parameters, not SecureString parameters, when used in CloudFormation dynamic references. Actually, CloudFormation supports {{resolve:ssm:...}} for SecureString, but it does not automatically apply NoEcho semantics—the resolved value may be visible in the template's resolved properties depending on the resource. More critically, Parameter Store does not provide native automatic rotation, cross-account secret sharing as seamlessly, or the same depth of integration with AWS KMS for enveloped encryption as Secrets Manager. While you can use {{resolve:ssm:/path/to/securestring}} and CloudFormation will not echo the value if the parameter is of type SecureString, this approach is generally less secure than the dedicated Secrets Manager dynamic reference because Parameter Store lacks built-in secret rotation and fine-grained audit logging specific to secret access. The question expects the more secure and modern practice of using Secrets Manager dynamic references.

• ✓

  Use a dynamic reference to AWS Secrets Manager secret in the CloudFormation template.

  Why this is correct

  A dynamic reference to Secrets Manager—written as {{resolve:secretsmanager:secret-id:secret-string:SecretString}} or similar—is a strong answer because CloudFormation retrieves the secret value at stack creation time and injects it into resource properties without ever exposing the secret in the template file. The resolved value is not stored in the stack template or shown in the console by default, and CloudFormation applies NoEcho semantics to dynamic reference outputs, preventing the secret from appearing in `DescribeStackEvents` or stack resource metadata. This approach is highly recommended when you need to manage secrets separately from infrastructure code, enable rotation, and control access via IAM conditions that refer to the Secrets Manager ARN. Because the secret is kept in a dedicated service, you avoid embedding secrets in templates and can audit access through CloudTrail.

• ✗

  Pass the password as user data to the EC2 instance and encrypt the user data.

  Why it's wrong here

  Passing the password as user data to an EC2 instance and encrypting the user data is flawed because user data is inherently a bootstrapping script that is stored in plaintext in the instance's metadata service (IMDSv1 potentially accessible without token) and visible to any process running on the instance. Even if you encrypt user data, the instance must decrypt it, which requires the decryption key to be available on the instance—effectively eliminating the security benefit unless you implement a complex key management process. The instance metadata service (IMDS) exposes user data to the instance itself, and any user with IAM permissions like `ec2:DescribeInstanceAttribute` can retrieve the user data; encryption does not hide the password from authorized principals who can access the instance. Moreover, user data is not designed or intended for secret management; it is for configuration. The correct approach is to reference a secret from Secrets Manager or use an EC2 instance role and a Secrets Manager SDK call at runtime, not to inline secrets into startup scripts.

Go deeper

Related to this question