DevOps and cloud interviews test how you build, ship and run software reliably: containers, CI/CD, cloud services, infrastructure as code and monitoring. Senior rounds add architecture and incident handling. These questions cover Docker, Kubernetes, AWS and day-to-day Linux.
Fundamentals, definitions and simple scenarios. Good for freshers and warm-ups.
Docker packages an application with its dependencies into an image, and a container is a running instance of that image. Containers share the host's operating system kernel and are isolated with namespaces and cgroups, so they start in seconds and use little memory. A virtual machine emulates hardware and runs a full guest operating system, which gives stronger isolation but is heavier and slower to start.
Continuous Integration means every push automatically builds the code and runs tests, so problems are caught early. Continuous Delivery keeps the main branch always deployable with a manual approval to release; Continuous Deployment releases to production automatically when the pipeline passes. A typical pipeline runs lint, tests, builds an image, runs a security scan, deploys to staging and then to production, using tools like GitHub Actions, GitLab CI or Jenkins.
git merge combines branches with a merge commit and keeps the full history as it happened. git rebase replays your commits on top of another branch, giving a straight, linear history, but it rewrites commit hashes. The golden rule is never to rebase a branch others are already using; rebase your own local work, merge shared branches.
top or htop for CPU and memory, free -h for memory, df -h and du for disk, ps aux to find processes, ss -tulpn or netstat to see listening ports, journalctl and tail -f for logs, systemctl status to check services, curl to test endpoints, and grep to search. Permissions are checked and fixed with ls -l, chmod and chown.
Applied problems, trade-offs and questions about your own projects.
A Pod is the smallest unit: one or more containers that share network and storage. A Deployment declares how many replicas of a Pod should run and handles rolling updates and rollbacks through ReplicaSets. A Service gives a stable DNS name and IP, and load-balances across the Pods matching its label selector; types include ClusterIP, NodePort and LoadBalancer. An Ingress routes outside HTTP traffic to Services.
Infrastructure as Code means defining servers, networks and other resources in files, with tools like Terraform or CloudFormation, instead of clicking in a console. The files are version-controlled, reviewed and reproducible across environments. In Terraform, plan shows what will change and apply makes the changes; the state file tracks real resources and should be stored remotely with locking so two people cannot apply at once.
Blue-green keeps two identical environments; you deploy to the idle one, test it, then switch all traffic over at once, and rollback is just switching back. It costs double the infrastructure during the switch. A canary release sends a small percentage of traffic to the new version, watches error rates and latency, and increases the share gradually. That limits the blast radius but needs good metrics and automation.
Secrets never go in source code, Docker images or plain config files. I store them in a secrets manager such as AWS Secrets Manager, HashiCorp Vault or encrypted Kubernetes Secrets, inject them at runtime, and grant access with least-privilege IAM roles. Secrets are rotated regularly, access is audited, and repositories are scanned so leaked keys are caught and revoked quickly.
System design, deep internals, leadership and tough follow-ups.
I spread everything across at least two Availability Zones: an Application Load Balancer in front of an Auto Scaling group, ECS or EKS running stateless app servers; RDS Multi-AZ with read replicas for the database; sessions in ElastiCache; static files on S3 behind CloudFront; Route 53 health checks. Everything is defined with Infrastructure as Code, backed up, and monitored in CloudWatch. If the recovery targets require it, I add a second region for disaster recovery.
Monitoring tracks known metrics and alerts when they cross thresholds. Observability is the ability to answer new questions about the system from its outputs: metrics, logs and traces together. I watch the four golden signals (latency, traffic, errors and saturation) with tools like Prometheus and Grafana, centralised logs, and distributed tracing through OpenTelemetry. Alerts are tied to user-facing service level objectives so the team is not flooded with noise.
First I stop the damage: roll back or turn off the feature flag, because restoring service comes before finding the cause. I tell stakeholders what is happening. Then I investigate with logs, metrics and the change diff, fix the problem with a test that would have caught it, and redeploy carefully. Afterwards we write a blameless postmortem covering the timeline, root cause and actions, such as better tests, canary releases or new alerts.
I use multi-stage builds so compilers and build tools are not in the final image, start from a slim or distroless base, and add a .dockerignore. I pin versions, order layers so caching works, and install only what is needed. The container runs as a non-root user, no secrets are baked into layers, and images are scanned with a tool like Trivy in the pipeline.