200-901 Application Deployment and Security Practice Question
A developer is building a Python microservice that will run in a Docker container on a shared host. The application must read its database connection string and API token from environment variables at runtime, and the developer wants to avoid baking those secrets into the image. Which approach best satisfies this requirement?
⚠ Common exam trap
The trap here is assuming that any use of environment variables is safe, when the Dockerfile ENV instruction permanently bakes the value into the image layer.
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
✓
Pass the values at runtime with docker run --env or --env-file so the process reads them from the container environment.
Secrets that must not persist in a distributed image should be supplied from outside the image at container start. Runtime environment injection keeps the image portable and secret-free, while Dockerfile instructions and source files permanently record whatever they contain. The requirement is about where the value lives, so the mechanism that never writes it into the image is the only one that satisfies it.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Copy a .env file containing the secrets into the image with the COPY instruction.
Why it's wrong here
Copying a .env file into the image places the secrets in an image layer that persists in the registry and in any local cache. Even deleting the file in a later layer leaves the data recoverable from the earlier layer. This is essentially the same failure as hardcoding the credentials and does not meet the requirement.
- ✗
Use the ENV instruction in the Dockerfile to set the connection string and token as defaults.
Why it's wrong here
The ENV instruction writes values permanently into the image layer, so anyone who pulls or inspects the image can read the connection string and token. That directly violates the goal of not baking secrets into the image, and rotating the credential would require rebuilding and republishing the image. It is the wrong mechanism for runtime-only secrets.
- ✓
Pass the values at runtime with docker run --env or --env-file so the process reads them from the container environment.
Why this is correct
Environment variables supplied at runtime are injected into the container process when it starts and are not stored in any image layer, so the published image stays free of secrets. The application reads them through the normal process environment, and rotating a credential only requires restarting the container with a new value, which matches the stated requirement exactly.
- ✗
Commit the secrets into the application's settings.py module so they load at import time.
Why it's wrong here
Embedding credentials in source code means they travel with the codebase into version control, build artifacts, and the image itself. Anyone with repository or image access can read them, and rotation requires a code change and redeployment. This is precisely the anti-pattern the developer is trying to avoid.
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.