SAA-C03 Design Secure Architectures Practice Question
A containerized service on Amazon ECS connects to a database with a password that must never be stored in plaintext or hardcoded in the image. The application reads the password at startup and occasionally reconnects later, so it needs to retrieve the current secret when needed. Which three actions should the architect take? Select three.
⚠ Common exam trap
The trap here is that candidates might think environment variables or IAM access keys are acceptable for secrets, but the exam requires using a dedicated secrets management service like Secrets Manager to avoid plaintext exposure and enable rotation.
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 database password in AWS Secrets Manager.
Option A is correct because AWS Secrets Manager is purpose-built to store sensitive values like database passwords encrypted at rest with KMS, so the password is never kept in plaintext or baked into the image. Option B is correct because the application must call the Secrets Manager API (e.g., GetSecretValue) at runtime each time it needs the credential, which also lets it pick up rotated values on later reconnects. Option C is correct because the ECS task role should be granted least-privilege IAM permissions scoped to just that secret's ARN (secretsmanager:GetSecretValue), so only the task can read it and nothing broader is exposed. Option D is wrong because a plain environment variable stores the password in cleartext and manual updates are error-prone and insecure. Option E is wrong because embedding the password in code and using long-lived IAM user access keys violates the requirement to avoid hardcoding and least-privilege credential management.
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 database password in AWS Secrets Manager.
Why this is correct
AWS Secrets Manager stores the credential encrypted with KMS and lets the ECS task retrieve it at runtime via the AWS SDK, so nothing is baked into the image or plaintext. This satisfies the requirement to fetch the current secret on each reconnect, and rotation keeps the retrieved value valid.
- ✓
Have the application retrieve the secret from Secrets Manager at runtime when it needs the password.
Why this is correct
Fetching the secret at runtime satisfies the requirement that the password is never hardcoded in the image or stored in plaintext. Because the application reconnects later, runtime retrieval also returns the current secret value rather than a stale copy cached at build time.
- ✓
Grant the ECS task role least-privilege permission to read only that secret.
Why this is correct
The ECS task role supplies temporary credentials to the container, so scoping it to read only that secret enforces least privilege. This lets the application call Secrets Manager without embedding long-lived AWS keys in the image, satisfying the no-plaintext constraint.
- ✗
Store the password in a plain environment variable and update it manually during maintenance windows.
Why it's wrong here
Plain environment variables are visible in the task definition and container metadata, so the password is effectively stored in plaintext, and manual updates cannot supply the current value on reconnect. It is tempting because environment variables are the standard way to pass non-sensitive configuration into containers.
When this WOULD be correct
In a non-production environment with no security compliance requirements, where the password is static and the application reads it from an environment variable set at container launch, and manual updates are acceptable for testing purposes.
- ✗
Use an IAM user access key inside the container so the database password can be embedded in code.
Why it's wrong here
Embedding the password in code or an IAM user access key stores credentials in plaintext and creates a long-lived identity, defeating the requirement. IAM user keys suit external integrations, not container workloads, which should assume a role and call Secrets Manager.
When this WOULD be correct
In a scenario where an application needs to authenticate to an external API that requires long-lived access keys and the application is running on an EC2 instance without IAM roles support, embedding an IAM user access key in a secure configuration file (not in code) might be acceptable if encrypted and rotated regularly.
Option-by-option analysis
Why each answer is right or wrong
Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The SAA-C03 exam frequently reuses these exact scenarios with slightly different constraints.
✓Store the database password in AWS Secrets Manager.Correct answer▾
Why this is correct
AWS Secrets Manager stores the credential encrypted with KMS and lets the ECS task retrieve it at runtime via the AWS SDK, so nothing is baked into the image or plaintext. This satisfies the requirement to fetch the current secret on each reconnect, and rotation keeps the retrieved value valid.
✗Store the password in a plain environment variable and update it manually during maintenance windows.Wrong answer — click to see why▾
Why this is wrong here
Storing the password in a plain environment variable violates the requirement that the password must never be stored in plaintext. Manual updates during maintenance windows are not secure and do not provide automated rotation or retrieval at runtime.
★ When this WOULD be the correct answer
In a non-production environment with no security compliance requirements, where the password is static and the application reads it from an environment variable set at container launch, and manual updates are acceptable for testing purposes.
Why candidates choose this
Candidates may think environment variables are a simple and acceptable way to pass secrets, overlooking the explicit requirement to avoid plaintext storage and the need for runtime retrieval without hardcoding.
✗Use an IAM user access key inside the container so the database password can be embedded in code.Wrong answer — click to see why▾
Why this is wrong here
Using an IAM user access key inside the container violates the principle of not storing secrets in the image or code, and access keys are long-lived credentials that increase security risk. The correct approach is to use IAM roles for tasks to obtain temporary credentials.
★ When this WOULD be the correct answer
In a scenario where an application needs to authenticate to an external API that requires long-lived access keys and the application is running on an EC2 instance without IAM roles support, embedding an IAM user access key in a secure configuration file (not in code) might be acceptable if encrypted and rotated regularly.
Why candidates choose this
Candidates may think that IAM access keys are a standard way to grant programmatic access, and they might not fully understand that ECS tasks can assume IAM roles, eliminating the need to embed keys.
Analysis generated from the official SAA-C03blueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”
Go deeper
Related to this question
About these practice questions
This SAA-C03 question is part of Courseiva's 935-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 SAA-C03 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 SAA-C03 exam.