Get the Preplance app for a seamless learning experience. Practice offline, get daily streaks, and stay ahead with real-time interview updates.
Get it on
Google Play
4.9/5 Rating on Store
Docker & Kubernetes · Question Set
Docker Images, Containers & Registries interview questions for placements and exams.
Questions
11
Included in this set
Subject
Docker & Kubernetes
Explore more sets
Difficulty
Mixed
Level of this set
Go through each question and its explanation. Use this set as a focused practice pack for Docker & Kubernetes.
Using a private registry allows you to host corporate images securely behind firewalls, control access and versions, reduce dependency on external repositories, and enforce compliance and image-scanning policies. It also gives you faster access in internal networks and avoids exposing proprietary application code.
For complete preparation, combine this set with full subject-wise practice for Docker & Kubernetes. You can also explore other subjects and sets from the links below.
`docker image prune` removes all dangling images (untagged images) and frees up disk space. Efficient image cleanup is important for CI/CD systems and build hosts to avoid storage bloat.
docker image prune -a
Multi-stage builds use multiple FROM statements in a Dockerfile. You build in one stage (with build tools) and then copy only the runtime artifacts into a slim final image. This reduces size, surface-area for vulnerabilities, and improves performance.
FROM golang:1.20 AS builder WORKDIR /app COPY . . RUN go build -o myapp FROM alpine:latest WORKDIR /app COPY --from=builder /app/myapp . CMD ["./myapp"]
Docker images may include outdated dependencies, unpatched libraries, mis-configured permissions, or embedded secrets. Mitigation includes using minimal base images, scanning images for vulnerabilities, removing unnecessary tools in runtime images, applying least-privilege user, regularly updating images, and applying image signing or trusted registries. This awareness is required for production readiness.
The `docker build` command reads instructions in a Dockerfile in the specified directory (here '.'), builds layers accordingly, and tags the resulting image as 'myimage'. This is foundational for custom image creation.
docker build -t myapp:latest .
Docker builds images in layers; when you rebuild, unchanged layers can be reused from cache. This leads to faster builds and smaller incremental changes. Knowing this helps optimize Dockerfile design.
Tags (such as ‘1.0’, ‘latest’, ‘release’) help you keep track of different versions of your image, facilitate roll-backs, and clarify what is running or being deployed in an environment.
Common mistakes include placing frequently changed instructions (like COPY . .) before less-frequently changed ones, triggering rebuilding of the same layers repeatedly; using heavy base images unnecessarily; leaving build tools and dependencies in runtime images; not combining RUN commands; and not using multi-stage builds. Optimising layering order, cleaning up caches and separating build/runtime environments avoids these issues.
Using unique tags (for example build number or git commit hash) ensures that each image is immutable, traceable and deployable. Relying only on ‘latest’ may lead to ambiguous versions and difficult rollbacks.
A Docker image is a read-only template that includes application code, libraries and runtime dependencies. A container is a live, running instance created from that image, with its own writable layer. Understanding this helps you differentiate build time (image) vs runtime (container).
You use `docker push <image>` to upload an image to a registry and `docker pull <image>` to download it. This is key for sharing and deploying images across hosts or teams.
docker push username/myapp:1.0 docker pull username/myapp:1.0