Image tags and versioning in Docker - Practice Problems & Coding Challenges

Challenge - 5 Problems

💻 Command Output

intermediate

Understanding Docker image tag output

What is the output of the command docker images --format "{{.Repository}}:{{.Tag}}" | grep '^myapp:' if the local images are:

• myapp:latest
• myapp:1.0
• myapp:1.1
• otherapp:2.0

Docker

docker images --format "{{.Repository}}:{{.Tag}}" | grep '^myapp:'

A No output

B

myapp:latest
myapp:1.0
myapp:1.1
otherapp:2.0

C otherapp:2.0

D

myapp:latest
myapp:1.0
myapp:1.1

💡 Hint

The grep command filters lines starting with 'myapp:'

The command lists all images with their repository and tag, then grep filters only those starting with 'myapp:'. So only the three 'myapp' tags appear.

🧠 Conceptual

intermediate

Docker image tag best practice

Which of the following is the best reason to avoid using the latest tag in production deployments?

A The latest tag is slower to download than versioned tags

B The latest tag always points to the newest image, which can cause unexpected updates breaking the app

C The latest tag cannot be pushed to Docker Hub

D The latest tag uses more disk space on the host

💡 Hint

Think about stability and predictability in production

Using 'latest' means you might pull a different image version than expected, causing unpredictable behavior. Versioned tags ensure you deploy a known image.

🔀 Workflow

advanced

Tagging and pushing multiple image versions

You built a Docker image locally with ID abc123. You want to tag it as myapp:1.0 and myapp:stable and push both tags to Docker Hub. Which sequence of commands correctly does this?

A

docker tag myapp:1.0 abc123
docker push myapp:1.0
 docker push myapp:stable

B

docker push abc123 myapp:1.0
 docker push abc123 myapp:stable

C

docker tag abc123 myapp:1.0
docker tag abc123 myapp:stable
docker push myapp:1.0
docker push myapp:stable

D

docker build -t myapp:1.0 .
docker push myapp:stable

💡 Hint

Remember to tag the image ID before pushing tags

You must tag the image ID with each tag, then push each tag separately. Option C does this correctly.

❓ Troubleshoot

advanced

Troubleshooting image pull failure with tags

You run docker pull myapp:2.0 but get the error manifest for myapp:2.0 not found. What is the most likely cause?

A The tag '2.0' does not exist in the remote repository

B The image name 'myapp' is invalid

C You have no internet connection

D Docker daemon is not running

💡 Hint

Check if the tag exists remotely

This error means Docker cannot find the specified tag in the remote repo. The tag might not have been pushed or was deleted.

✅ Best Practice

expert

Versioning strategy for Docker images in CI/CD

In a CI/CD pipeline, which tagging strategy best supports traceability and rollback of Docker images?

A Tag images with the Git commit SHA and push with that tag

B Always tag images as 'latest' to simplify deployment

C Use timestamps as tags without linking to source code

D Tag images only with semantic version numbers like 1.0, 1.1

💡 Hint

Think about linking image versions to exact code changes

Tagging with Git commit SHA links the image to the exact source code version, enabling precise traceability and rollback.