200-901 Application Deployment and Security Practice Question
A developer pushes a container image to Docker Hub and then discovers that the image layers contain an .env file with production API keys. The team wants future builds to fail automatically in the CI pipeline when secrets are detected in the image before any push occurs. Which approach best addresses this requirement?
⚠ Common exam trap
The trap here is assuming that excluding a secrets file from the build context is equivalent to detecting secrets in the final image.
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
✓
Run a container image scanning tool against the built image in the pipeline and fail the stage when secret findings are reported.
The requirement is detection with an automatic pipeline failure before pushing. Scanning the built image examines the exact artifacts destined for the registry, so secrets leaked through any path are found. Wiring the scanner to exit non-zero on findings turns that detection into a hard gate. Preventive measures like .dockerignore or signing policies reduce risk but cannot guarantee that no secret exists in the image.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Enable Docker Content Trust so that only signed images can be pushed to Docker Hub.
Why it's wrong here
Docker Content Trust enforces image signing and verification of publisher identity and integrity; it does not inspect layer contents for credentials. A signed image can still contain a leaked .env file, so enabling content trust would not cause the pipeline to fail on secret detection and does not satisfy the scenario requirement.
- ✗
Store the API keys in Docker Hub repository secrets and reference them from the Dockerfile at build time.
Why it's wrong here
Docker Hub does not provide a build-time secret store that injects values into a local docker build in the way described, and even where build secrets exist they are designed to keep values out of layers rather than to detect previously leaked ones. This does not create a detection gate that fails the pipeline when secrets are found in an image.
- ✓
Run a container image scanning tool against the built image in the pipeline and fail the stage when secret findings are reported.
Why this is correct
Scanning the built image in the pipeline inspects the actual layers that would be pushed, detecting secrets wherever they were introduced, including base layers and hardcoded values. Configuring the scan stage to return a non-zero exit status on findings makes the pipeline fail before the push step executes, which is exactly the requested automatic gate.
- ✗
Add a .dockerignore entry for .env and rely on developers to never commit secrets.
Why it's wrong here
Excluding .env with .dockerignore prevents that specific file from entering the build context, but it is a preventive hygiene measure, not a detection gate. It cannot catch secrets baked into other files, hardcoded in source, or introduced by a base layer, so it will not make the pipeline fail when secrets are present in the built image.
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.