200-901 Application Deployment and Security Practice Question
A developer has built a container image locally and needs to push it to Docker Hub so a CI runner can pull it. The image is currently tagged only as `webapp:latest`. The Docker Hub repository is `devopsuser/webapp`. Which command sequence correctly prepares and uploads the image?
⚠ Common exam trap
The trap here is assuming docker push can target a repository path that differs from the local image tag, when the tag itself must already match the destination.
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
✓
docker tag webapp:latest devopsuser/webapp:latest followed by docker push devopsuser/webapp:latest
Publishing to a namespaced registry repository requires the local image reference to include that namespace and repository name. Retagging the existing artifact preserves the exact image that was built and tested, then push uploads it to the matching remote path. Creating a new image through commit, save, or a fresh build either fails outright or changes the artifact unnecessarily.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
docker commit webapp:latest devopsuser/webapp:latest followed by docker push devopsuser/webapp:latest
Why it's wrong here
docker commit creates a new image from a container's writable layer, not from an existing image reference. Passing an image name as the container argument fails because commit expects a running or stopped container ID or name. Even if a container existed, this would capture filesystem changes rather than simply retag the already-built image.
- ✗
docker build -t devopsuser/webapp:latest . followed by docker push devopsuser/webapp:latest
Why it's wrong here
Rebuilding with the desired tag does produce a correctly named image, but it discards the already-built artifact and requires the build context and Dockerfile to reproduce it identically. The scenario states the image already exists locally, so a fresh build is unnecessary and risks producing a different image than the one tested. Retagging is the intended low-risk operation.
- ✗
docker save webapp:latest -o devopsuser/webapp:latest followed by docker push devopsuser/webapp:latest
Why it's wrong here
docker save exports an image to a tar archive on the local filesystem; it does not create a registry-ready tag. The filename devopsuser/webapp:latest is just a path on disk, and the push would still fail because no local image carries that repository name. Save is used for offline transfer, not for registry publication.
- ✓
docker tag webapp:latest devopsuser/webapp:latest followed by docker push devopsuser/webapp:latest
Why this is correct
Docker push requires the local image tag to match the remote repository path, including the namespace. Retagging as devopsuser/webapp:latest creates that qualified reference, and the subsequent push targets the same repository. Without the namespace prefix, the daemon would attempt to push to an implicit library repository and fail authentication or not find the target.
Go deeper
Related to this question
About these practice questions
This 200-901 question is part of Courseiva's 975-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam 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.