easyMultiple Choice
200-901 Practice Question: A developer is deploying a containerized…
A developer is deploying a containerized application to a Kubernetes cluster. To ensure that the application can securely access a third-party API, what is the best practice for storing the API key?
⚠ Common exam trap
200-901 often tests the Secret vs ConfigMap distinction — candidates pick ConfigMap because both store key-value data, but only Secrets are intended for sensitive credentials, and the exam expects you to know that distinction.
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 it as a Kubernetes Secret and mount it as an environment variable.
Storing the API key as a Kubernetes Secret and mounting it as an environment variable is correct because Secrets are the native Kubernetes mechanism for holding sensitive data such as API keys, passwords, and tokens. They are stored separately from pod specifications and can be injected as environment variables or mounted volumes, keeping credentials out of container images and source code.
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 it as a Kubernetes Secret and mount it as an environment variable.
Why this is correct
Kubernetes Secrets hold sensitive data separately from the pod spec and image, satisfying the requirement to avoid hard-coding the API key. Mounting it as an environment variable injects the credential at runtime, so the container authenticates to the third-party API without exposing the key in source control or the image layer.
- ✗
Hardcode the API key in the Docker image.
Why it's wrong here
Hardcoding the key in the image embeds it in every layer and registry copy, exposing it to anyone who can pull the image and preventing rotation without a rebuild. It is tempting as the quickest way to get the container running, and would suit a disposable local test image where no real credentials exist.
- ✗
Use a service account token.
Why it's wrong here
A service account token authenticates the pod to the Kubernetes API server, not to a third-party API, so it cannot supply that external credential. It is tempting because service accounts are the standard identity mechanism inside a cluster, and would be correct for granting a workload access to Kubernetes resources.
- ✗
Store it in a ConfigMap and reference it from the pod.
Why it's wrong here
ConfigMaps hold non-confidential configuration as plaintext, so the API key is readable by anyone with get access to the namespace. They are tempting because pods consume them easily as environment variables or files, and they would be the right choice for non-sensitive settings such as feature flags or log levels.
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.