SCS-C02 Infrastructure Security Practice Question
A company uses AWS CloudFormation to deploy infrastructure. The security team wants to ensure that no sensitive data, such as database passwords, is exposed in plaintext in the CloudFormation templates. What is the MOST secure way to handle secrets?
⚠ Common exam trap
Candidates often think encrypting the secret with KMS (Option A) or storing it in an encrypted S3 bucket (Option C) is sufficient, but they overlook that the encrypted data or reference URL is still exposed in the template, and the decryption key or bucket access must be managed separately, which is less secure than using a dedicated secrets service with dynamic references.
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 or AWS Secrets Manager with dynamic references in the template.
AWS Systems Manager Parameter Store and AWS Secrets Manager support dynamic references in CloudFormation templates, allowing you to reference secret values without exposing them in plaintext. CloudFormation resolves these references at deployment time, retrieving the actual secret value from the secure store, and never stores the secret in the template or stack metadata. This approach ensures secrets are managed, rotated, and audited centrally, adhering to security best practices.
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 KMS to encrypt the secrets and include the ciphertext in the template.
Why it's wrong here
Including KMS-encrypted ciphertext directly in a CloudFormation template gives a false sense of security: the ciphertext is static and visible to anyone who can read the template, and any IAM principal holding decrypt permission on that KMS key can decrypt it offline. CloudFormation also stores the template and stack metadata, so the ciphertext persists in AWS, expanding the exposure surface. This approach merely obfuscates rather than prevents access, and it couples secret safety to the KMS key policy without any of the lifecycle or rotation features that a dedicated secrets service provides.
- ✓
Use AWS Systems Manager Parameter Store or AWS Secrets Manager with dynamic references in the template.
Why this is correct
Using CloudFormation dynamic references to AWS Systems Manager Parameter Store or AWS Secrets Manager lets the service fetch the secret value at stack create/update time, so the actual secret never appears in the template, AWS CloudFormation API calls, or stack logs. With a parameter reference like 'ssm-secure:MyParameter' or a secretsmanager reference, CloudFormation passes the resolved value directly to the resource while the template retains only the reference. This aligns with least-privilege access and supports rotation, because you can attach a version to the reference and rotate the backing secret without editing the template.
- ✗
Store the secrets in an encrypted S3 bucket and include the S3 URL in the template.
Why it's wrong here
Referencing a secret by its S3 URL inside an encrypted object makes the bucket location visible to every template reader and exposes an extra attack surface of S3 policies, bucket ACLs, and cross-account access. A user who can read the template can attempt to fetch the object, and if the object is retrieved, there is no CloudFormation-native way to guarantee that the caller also has decrypt permission. It also introduces an extra dependency on S3 versioning/object lifecycle for the secrets, whereas a dynamic reference removes the need to store or manage secrets as object downloads.
- ✗
Pass the secrets as plaintext parameters to the stack at launch time.
Why it's wrong here
Passing secrets as plaintext CloudFormation parameters means the values are kept in the template, in the stack's Parameters data, and in the API/console history, so anyone with cloudformation:DescribeStacks sees them in clear text. The NoEcho attribute only suppresses display in the console parameter input, not the resolved values in logs or events, and it does not encrypt the value in the stack metadata. This leaks data by design and violates the principle of not persisting plaintext secrets in infrastructure-as-code artifacts.
Visual reference
Go deeper
Related to this question
About these practice questions
This SCS-C02 question is part of Courseiva's 1,205-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This SCS-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 SCS-C02 exam.