DOP-C02 Configuration Management and IaC Practice Question
A company uses AWS CloudFormation to manage its infrastructure. The DevOps team has a template that creates an Amazon RDS DB instance and an EC2 instance that runs a web application. The EC2 instance needs to connect to the RDS instance using the database endpoint and password. The team currently passes the endpoint and password as CloudFormation parameters, which are then stored in the EC2 instance's user data. However, security audit has flagged this as a security risk because the password is visible in the user data. The team wants to securely pass the database credentials to the EC2 instance without exposing them in the template or user data. The EC2 instance has an IAM role that allows it to read from AWS Secrets Manager. Which solution should the team implement?
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
✓
Store the password in AWS Secrets Manager, use a dynamic reference to pass it to the EC2 instance's IAM role, and have the application retrieve it from Secrets Manager at runtime.
By storing the password in AWS Secrets Manager and using a dynamic reference in CloudFormation, the password is never exposed in the template or user data. The EC2 instance retrieves the password from Secrets Manager at runtime using its IAM role. Option A is not the best because although Parameter Store can store SecureStrings, Secrets Manager is more secure and supports automatic rotation, and the instance already has permissions to read Secrets Manager. Option B is risky because encrypting user data still exposes the password in the user data itself and adds key management complexity. Option D is wrong because Fn::GetAtt cannot retrieve the RDS master password, and even if it could, the password would still be passed via user data, which is insecure.
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 in AWS Systems Manager Parameter Store as a SecureString and have the EC2 instance retrieve it using the AWS CLI.
Why it's wrong here
Parameter Store SecureString parameters are encrypted with a KMS key, but CloudFormation dynamic references for SecureString are supported only in select resource properties (e.g., some resource attributes), and invoking the AWS CLI on the instance still requires the password to be handled in shell scripts or command history. It also lacks native rotation for RDS credentials, so the password would remain static unless you build a custom rotation Lambda function. This approach improves on plaintext but does not fully decouple the secret from the instance.
- ✗
Encrypt the user data using AWS KMS and decrypt it on the EC2 instance at boot time.
Why it's wrong here
Encrypting user data with KMS only changes the representation, not the exposure: the ciphertext and the KMS key ARN are present in the CloudFormation template, and any instance role with kms:Decrypt permission can decrypt it to plaintext at boot. The decrypted password then resides in the instance's user data execution environment or local files, so the secret is still effectively present on the machine. CloudFormation does not natively support encrypting arbitrary user data fields with KMS dynamic references, so this misleads on security.
- ✓
Store the password in AWS Secrets Manager, use a dynamic reference to pass it to the EC2 instance's IAM role, and have the application retrieve it from Secrets Manager at runtime.
Why this is correct
This is correct because the password is stored and rotated in AWS Secrets Manager, and the CloudFormation template only references the secret's ARN (e.g., via a dynamic reference) in the IAM role policy, enabling the EC2 instance to read it. No secret value ever enters the template, user data, or instance filesystem; the application retrieves the plaintext only when it calls Secrets Manager at runtime. Since the IAM role restricts access to only that secret and Secrets Manager supports automatic rotation, the approach satisfies security best practices.
- ✗
Use CloudFormation's Fn::GetAtt to retrieve the password from the RDS instance and pass it to the EC2 instance via user data.
Why it's wrong here
Fn::GetAtt on an RDS DBInstance only supports certain attributes such as Endpoint.Address or MasterUserSecret.SecretArn; it does not return the master password as plaintext, even when the password is managed by Secrets Manager. Even if a workaround existed, embedding the password in user data exposes it to any process running on the instance and to anyone with access to the launched instance's metadata or logs. A managed secret should be referenced by ARN, not copied into user data.
Go deeper
Related to this question
About these practice questions
One of 1,013 original DOP-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 →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This DOP-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 DOP-C02 exam.