200-901 Application Deployment and Security Practice Question
A security team is reviewing a CI/CD pipeline that builds container images and pushes them to a registry. They want to reduce the attack surface of the resulting images and ensure that only trusted images are deployed. Which TWO practices should be implemented? (Choose two.)
⚠ Common exam trap
The trap here is treating image signing as sufficient on its own, when trust also depends on shrinking what actually runs inside the 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
✓
Sign images with a tool such as Docker Content Trust or cosign and enforce signature verification in the admission controller before workloads are scheduled.
Reducing image attack surface comes from shipping only what the application needs, which multi-stage builds and minimal base images accomplish by stripping compilers, shells, and unused packages. Ensuring only trusted images deploy requires cryptographic signing plus enforcement, so verification happens before scheduling. Together these controls address both halves of the requirement, while root execution, embedded secrets, and disabled scanning all weaken the posture.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Sign images with a tool such as Docker Content Trust or cosign and enforce signature verification in the admission controller before workloads are scheduled.
Why this is correct
Signing images produces cryptographic proof of who built and published them. Enforcing verification at admission time, for example with a policy engine or cosign-backed admission controller, ensures only images with valid signatures from trusted publishers can run. This satisfies the requirement that only trusted images are deployed, even if an attacker compromises the registry.
- ✗
Run the container as the root user inside the image so that package installation and file permission changes succeed during startup.
Why it's wrong here
Running as root increases the impact of any container escape or application compromise, because the process has broad privileges inside the container and potentially on the host depending on configuration. It does not reduce attack surface; it enlarges it. Best practice is to create a non-root user and set the USER instruction, so this option contradicts the stated goal.
- ✗
Disable the registry's vulnerability scanning feature to speed up pipeline execution and avoid false-positive build failures.
Why it's wrong here
Turning off vulnerability scanning removes a key control for detecting known CVEs in base images and dependencies. It improves pipeline speed at the cost of visibility into exactly the risks the team wants to reduce. Scanning is complementary to minimal images and signing, and disabling it works against both goals of reducing attack surface and ensuring trust.
- ✓
Use multi-stage builds and a minimal base image such as distroless or Alpine to exclude build tools and unnecessary packages from the final image.
Why this is correct
Multi-stage builds let you compile or install dependencies in an intermediate stage and copy only the required artifacts into the final image. Pairing that with a minimal base like distroless or Alpine removes shells, package managers, and compilers that attackers could abuse. Fewer packages mean fewer known vulnerabilities, directly reducing the image attack surface as the team requested.
- ✗
Bake environment-specific secrets into the image at build time using ARG values so the container is self-contained.
Why it's wrong here
Embedding secrets in image layers is dangerous because layers are retained in the registry and can be extracted by anyone with pull access, even if later layers delete the files. This increases exposure rather than reducing attack surface and has nothing to do with ensuring trusted images. Secrets should be injected at runtime from a secret manager or orchestrator secret.
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.