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
Tech Mahindra · Docker & Kubernetes
Practice Docker & Kubernetes questions specifically asked in Tech Mahindra interviews – ideal for online test preparation, technical rounds and final HR discussions.
Questions
23
Tagged for this company + subject
Company
Tech Mahindra
View company-wise questions
Subject
Docker & Kubernetes
Explore topic-wise practice
Go through each question and its explanation. Use this page for targeted revision just before your Tech Mahindra Docker & Kubernetes round.
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 company + subject page with full company-wise practice and subject-wise practice. You can also explore other companies and topics from the links below.
Unlike VMs which include a full guest operating system and hypervisor overhead, containers share the host’s OS kernel and are much lighter, start faster and use fewer resources. This makes them ideal for microservices and repeatable deployments. :contentReference[oaicite:1]{index=1}
In docker-compose.yml you use `depends_on:` to make one service wait until the other has been started. It does *not* guarantee the dependent service is fully ready — only that it has been started.
services:
web:
depends_on:
- dbSome best practices include: Use a minimal base image (for example Alpine or slim variants) to reduce image size. Combine RUN commands to reduce intermediate layers. Clean up temporary files in the same RUN statement. Use multi-stage builds where possible to separate build and runtime dependencies. Tag and version your images clearly. Avoid running as root inside the container unless necessary. Understand that image size, layer count and caching affect build performance and deployment speed.
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 .
A Dockerfile is a text file containing instructions (FROM, COPY, RUN, CMD etc) which Docker uses to build an image layer by layer. It defines how the image is constructed. This supports reproducible builds and versioning. :contentReference[oaicite:4]{index=4}
FROM node:14 WORKDIR /app COPY . . RUN npm install CMD ["node","index.js"]
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.
One way is to mount the volume into a temporary container, use `docker run --rm -v volume_name:/backup ubuntu tar czf /backup/data.tar /mountpoint` to archive the data, copy the archive to the other host (scp/s3), then on the destination create a volume and restore with `tar xzf data.tar -C /mountpoint`. You could also use `docker cp` or storage driver snapshotting. Having a repeatable strategy for data migration helps avoid loss of data in production.
Docker Swarm is Docker’s built-in orchestration system. It allows you to run services across multiple nodes, manage desired state, replicate containers, and provide basic scheduling and load balancing.
Compose profiles let you tag services with `profiles: ["dev"]` or `profiles: ["prod"]`. When running `docker compose --profile prod up` only services tagged for prod plus default run. This helps reuse the same compose file for multiple environments. Refer to official docs.
Namespaces provide a scope for names and resource allocation in a Kubernetes cluster, enabling isolation between teams, environments (dev/test/prod) and users.
Labels are key-value pairs assigned to Kubernetes objects. Selectors match against labels so services, ReplicaSets, Deployments and other controllers can act on the correct set of objects. Understanding how labels and selectors interplay is crucial for dynamic grouping and management of resources.
The `kubectl cordon` command marks a node unschedulable so no new pods are placed on it. After cordon you typically run `kubectl drain` to evict existing pods safely before maintenance.
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.
A Container Network Interface (CNI) plugin is responsible for providing networking for pods: allocating IP addresses, configuring interfaces, managing routing and enforcing network policies. Choosing the correct CNI is vital for security, performance and multi-node networking.
In a canary deployment you deploy a new version to a subset of traffic and monitor metrics and logs before making it the main version. This reduces risk and enables you to detect issues early without affecting all users. It is widely supported in Kubernetes via traffic-splitting tools or service mesh integrations.
Taints applied to nodes repel certain pods unless the pods have matching tolerations. This mechanism allows you to prevent or restrict scheduling of pods on nodes with special characteristics like maintenance, hardware failures or dedicated workloads, enhancing cluster resilience and resource isolation.
When a pod stays in ContainerCreating it often means the container runtime is downloading the image or waiting on credentials or storage mount. Investigating `kubectl describe pod`, image registry access, pull secrets and node storage readiness helps diagnose this hang.
In this scenario I would first check pod logs with `kubectl logs --previous <pod>` to understand what error caused the crash. I’d then inspect the new version’s readiness and liveness probe configurations and compare with the last working version. While investigating I would immediately initiate a rollback using `kubectl rollout undo deployment/<service>`, or switch traffic to a stable replica set or version if available. Communication is critical: I’d notify stakeholders of the issue, the rollback action, expected downtime and recovery timeline. Next I would analyse root cause: maybe a dependency changed, environment variable missing, or database schema mismatch. I’d capture metrics, alert teams, fix the issue in a development environment, test it, then re-deploy with monitoring. After resolution I’d coordinate a post-mortem with stakeholders summarising what happened, impact, fix and preventive actions. This demonstrates production-grade discipline. :contentReference[oaicite:1]{index=1}
Using GitOps means your Git repository is the single source of truth for desired state, and an operator controller watches for changes and applies them to the cluster. Blocking manual changes and enforcing reconciliation helps prevent configuration drift, a common interview scenario. :contentReference[oaicite:4]{index=4}
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
A StatefulSet is used for applications that require stable network identifiers, ordered start-up or shutdown, and persistent storage tied to each replica (for example databases or message queues). When using a StatefulSet you must ensure each replica has a PersistentVolumeClaim bound to appropriate storage, define a StorageClass for dynamic provisioning, and consider storage performance, retention and backup. Using StatefulSet correctly is key for stateful workloads in Kubernetes production setups.
GitOps is a paradigm where your infrastructure and application desired state (manifests, Helm charts) live in Git. A controller watches for changes and reconciles the cluster to match that state. This offers higher auditability, controlled roll-backs and aligns operations with developer workflows.