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
Kubernetes Deployments interview questions for placements and exams.
Questions
10
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.
You can use `kubectl rollout undo deployment/<name>` to revert a Deployment to its previous revision. Kubernetes keeps a history of revisions (by default a limited number) and this command restores the earlier state, enabling safer rollbacks.
kubectl rollout undo deployment/myapp
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.
A readiness probe determines when a pod is ready to receive traffic, so it won’t be sent requests until this probe passes. A liveness probe determines whether the container is alive and should be restarted if it fails. Using both correctly ensures stable and healthy deployments.
A Deployment object declares how many replicas of an application should be running and handles updates, rollbacks and scaling for those replicas. It offers a declarative way to manage the lifecycle of stateless applications.
The fields `maxSurge` and `maxUnavailable` in a Deployment control how many new pods are created above the desired count and how many old pods can be unavailable during the update. This governs the pace and safety of rolling updates.
If only limits are defined, the scheduler does not have a clear baseline of requested resources, which may lead to inefficient placement or contention. Requests define what is guaranteed and used for scheduling, while limits cap consumption.
Immutable configuration means you treat your Deployment manifest, container image and config data as unchangeable once released, and instead deploy new versions rather than mutate running ones. This approach improves auditability, rollback safety and reproducibility. By deploying a new image tag or changing spec and applying a new Deployment, you ensure a clean, known state rather than chasing configuration drift.
A canary strategy runs the new version alongside the old one and gradually shifts traffic, while Blue-Green normally switches all traffic at once to a new version and retains the old version for rollback. Choosing the right strategy depends on risk tolerance, traffic volume and rollback complexity.
Some best practices include: keep manifests version-controlled, avoid embedding secrets directly in YAML, use clear labels and annotations, keep resource requests and limits defined, break down large manifests into logical units, tag images with immutable versions, reuse templates with Kustomize or Helm, and validate schema with tools like kube-lint. These practices help maintain reliability, clarity and ease of maintenance.
You can pause a rollout using `kubectl rollout pause deployment/<name>` to stop applying changes mid-update, inspect behavior and then resume with `kubectl rollout resume`. This is useful when you want to verify a new version before full deployment.
ConfigMaps store non-sensitive configuration data and Secrets store sensitive information such as passwords or keys. In a Deployment you can mount them as volumes or expose them as environment variables. Using them separately improves security, makes configuration more flexible, and separates code from configuration. For example you might store database URL in a ConfigMap and database credentials in a Secret, then inject them into your pods at runtime rather than building them into the image.