CCSP Cloud Application Security Practice Question
A company develops a microservices application and wants to ensure secrets such as API keys and database credentials are not exposed in container images. Which approach best meets this requirement?
⚠ Common exam trap
ISC2 often tests the misconception that environment variables are a secure way to pass secrets because they are not in the image, but the trap is that environment variables are still exposed in the container's runtime environment and orchestration metadata, making them vulnerable to leakage via logs, debugging tools, or misconfigured RBAC.
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 a secrets management service such as HashiCorp Vault to inject secrets at runtime.
A secrets management service like HashiCorp Vault allows secrets to be dynamically injected into containers at runtime, ensuring they never reside in the image. This approach decouples secrets from the application artifact, adhering to the principle of least privilege and immutable infrastructure. Vault can inject secrets via sidecar containers, init containers, or API calls, preventing exposure in image layers or configuration files.
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 secrets in the application code and obfuscate with encryption.
Why it's wrong here
Obfuscated secrets still reside in the image layers and code repository, so anyone pulling the image can extract them; encryption without external key management is reversible. It is tempting because it requires no orchestration changes, and would suit a throwaway local prototype where no shared registry or untrusted parties exist.
- ✓
Use a secrets management service such as HashiCorp Vault to inject secrets at runtime.
Why this is correct
HashiCorp Vault stores credentials outside the image and injects them into the container at runtime, so no secret is baked into layers or environment variables. This satisfies the requirement that API keys and database credentials never appear in container images, where they would be extractable.
- ✗
Pass secrets as environment variables during container deployment.
Why it's wrong here
Environment variables are visible via container inspection, /proc, crash dumps and orchestration manifests, so secrets leak outside the image boundary. It is tempting because it is trivial to implement and suits non-sensitive configuration such as log levels or feature flags, where disclosure causes no credential compromise.
- ✗
Store secrets in a separate configuration file within the image.
Why it's wrong here
A configuration file baked into the image is stored in its layers and remains readable by anyone who pulls it, so the secret is still exposed. It is tempting because it separates secrets from code and suits static, non-sensitive settings like timeouts or endpoint URLs that carry no authentication value.
Go deeper
Related to this question
About these practice questions
One of 934 original CCSP 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 CCSP practice question is part of Courseiva's free ISC2 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 CCSP exam.