200-901 Application Deployment and Security Practice Question
An application deployed on a Kubernetes cluster must call an external payment API. The security team requires that the API credential never be stored in the container image, never appear in the pod specification, and be rotatable without rebuilding or redeploying the application. Which approach meets all three requirements?
⚠ Common exam trap
The trap here is assuming that any use of a Kubernetes Secret satisfies the requirements, when how it is consumed determines whether rotation needs a redeploy.
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
✓
Mount the credential from a Kubernetes Secret as a volume and have the application read the file on each request.
The constraints point to keeping the credential outside the image and outside the manifest while allowing live updates. A Secret mounted as a volume achieves that, and kubelet periodically syncs the mounted files from the API object. An application that reads the file per request picks up the rotated value without any rebuild or rollout, unlike inline environment variables or arguments that require redeployment.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Define the credential as an environment variable in the Deployment manifest and reference it from application code.
Why it's wrong here
Defining the value directly in the Deployment manifest embeds the credential in the pod specification, which is explicitly forbidden, and anyone who can read the Deployment object can read the secret. Rotation would also require editing the manifest and triggering a rollout, failing the no-redeploy requirement.
- ✗
Pass the credential to the container as a command-line argument in the pod specification.
Why it's wrong here
Command-line arguments are part of the pod specification and are also visible to anyone who can inspect the process list inside the container, so the credential would appear in the manifest. Rotation would require editing the Deployment and restarting pods, which fails the requirement to avoid redeployment.
- ✗
Bake the credential into the image as a file and mount it into the container at startup.
Why it's wrong here
Baking the credential into the image violates the first requirement and leaves it recoverable from image layers even if a later layer deletes it. Rotation would require rebuilding and republishing the image, and every environment would share the same embedded value, so the approach fails multiple stated constraints.
- ✓
Mount the credential from a Kubernetes Secret as a volume and have the application read the file on each request.
Why this is correct
A Secret mounted as a volume keeps the value out of the image and out of the pod specification, and kubelet refreshes the projected files when the Secret is updated. Having the application re-read the file per request means rotation takes effect without a rebuild or redeploy, satisfying all three constraints in the scenario.
Go deeper
Related to this question
About these practice questions
One of 975 original 200-901 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 and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Cisco exam blueprint
This 200-901 practice question is part of Courseiva's free Cisco 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 200-901 exam.