200-901 Software Development and Design Practice Question
A team is containerizing a Python API service so it can run identically on developer laptops and in production. Which TWO practices support reproducible, portable container images for this service? (Choose two.)
⚠ Common exam trap
The trap here is believing that using a Dockerfile alone guarantees consistency, when floating base images, unpinned dependencies, or build-time secrets each break reproducibility or portability.
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
✓
Pin the base image to a specific digest and declare exact dependency versions in a lock file installed during the build.
Reproducibility requires that the same inputs always produce the same image, which means pinning the base image and locking dependencies. Portability requires that environment differences be supplied at runtime, not baked in, so one tested artifact can move from laptop to production unchanged. Together these practices make builds deterministic and keep secrets out of image layers.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Pin the base image to a specific digest and declare exact dependency versions in a lock file installed during the build.
Why this is correct
Pinning the base image by digest and locking dependency versions ensures every build resolves to the same layers and packages, so the image produced on a laptop matches the one built in CI. Without pinning, a silently updated base image or library can change behavior between environments, undermining reproducibility and making failures hard to trace.
- ✗
Bake environment-specific API tokens and database passwords into the image as build arguments so the container starts ready to use.
Why it's wrong here
Embedding secrets in image layers stores them permanently in the image history and registry, where anyone who can pull the image can extract them. It also ties one artifact to one environment, defeating portability. Secrets should be injected at runtime through a secrets manager or orchestrator, not compiled into the image.
- ✓
Inject environment-specific configuration and secrets at runtime through environment variables or a secrets manager rather than at build time.
Why this is correct
Runtime injection keeps a single immutable image promotable across environments, since only the supplied configuration changes. Secrets never enter the image or its layer history, reducing exposure in registries and CI logs. This aligns with twelve-factor configuration and is the recommended pattern for containerized services that must behave consistently from laptop to production.
- ✗
Install dependencies from the public index without version constraints and rebuild the image on every deployment to pick up the latest packages.
Why it's wrong here
Unconstrained installs resolve to whatever is newest at build time, so the same Dockerfile can produce different images on different days. A breaking upstream release can change behavior between laptop and production with no code change. Rebuilding on each deployment also discards the benefit of a tested, immutable artifact, harming reproducibility.
- ✗
Mount the developer's local source directory over the application path inside the production container to keep code current.
Why it's wrong here
Bind-mounting local source into production bypasses the tested image contents and makes the running service depend on files on a specific host. Two hosts with different working copies would behave differently, and the image no longer represents what runs. Volume mounts are useful for local development hot reload, but they break the portability and reproducibility the team is trying to achieve.
Go deeper
Related to this question
About these practice questions
Courseiva writes every 200-901 question from scratch — 975 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. 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.