Whether you're preparing for your first DevOps role or targeting a senior platform engineering position, this guide covers 50 real-world interview questions you'll actually encounter in 2026. Each answer is written the way you'd deliver it in an interview — concise, practical, and backed by experience.
Questions are tagged by level: [Junior] for entry-level, [Mid] for 2-5 years experience, and [Senior] for staff/principal roles.
---
1. Linux & Networking (Questions 1-10)
Q1. How do you find and kill a process consuming high CPU? [Junior]
Answer: I'd run top or htop to identify the PID of the offending process. Once identified, I use kill -15 <PID> for a graceful termination, or kill -9 <PID> if it's unresponsive. For a scripted approach, ps aux --sort=-%cpu | head -10 gives me the top CPU consumers instantly.
Bonus point: Mention that SIGTERM (15) allows cleanup handlers to run while SIGKILL (9) is immediate and can leave orphaned resources. In production, always try SIGTERM first and only escalate to SIGKILL after a timeout.
---
Q2. Explain the difference between soft and hard links. [Junior]
Answer: A hard link is an additional directory entry pointing to the same inode — the file persists until all hard links are removed. A soft link (symlink) is a pointer to a file path, so it breaks if the original is deleted. Hard links can't cross filesystem boundaries or link to directories, while symlinks can do both.
Bonus point: Mention that Docker uses symlinks extensively in /var/lib/docker because container layers use different filesystems where hard links won't work.
---
Q3. What happens when you type a URL in the browser? Explain the networking flow. [Junior]
Answer: DNS resolution converts the domain to an IP (checking local cache, then recursive resolvers). A TCP three-way handshake establishes the connection. If HTTPS, a TLS handshake negotiates encryption. The HTTP request travels to the server, which processes it and returns a response. The browser renders the HTML, fetching additional assets as needed.
Bonus point: Mention connection pooling with HTTP/2 multiplexing, and how CDNs short-circuit this flow by serving from edge locations closer to the user, reducing round-trip time.
---
Q4. How do you troubleshoot a Linux server that's running out of disk space? [Junior]
Answer: First, df -h shows filesystem usage. Then du -sh /* | sort -rh | head -20 identifies the largest directories. Common culprits are log files (/var/log), old Docker images, or temp files. I'd also check for deleted files still held open with lsof +L1 — these consume space until the process releases them.
Bonus point: In production, mention setting up log rotation with logrotate, using journalctl --vacuum-size=500M for systemd journals, and automating Docker cleanup with docker system prune in a cron job.
---
Q5. Explain TCP vs UDP and give DevOps-relevant use cases. [Mid]
Answer: TCP provides reliable, ordered delivery with congestion control — used for HTTP, SSH, and database connections where data integrity matters. UDP is connectionless and faster but unreliable — used for DNS lookups, metrics collection (StatsD), container networking (VXLAN overlays), and video streaming. In DevOps, understanding this matters for firewall rules, load balancer configuration, and service mesh tuning.
Bonus point: Mention that Kubernetes uses UDP for CoreDNS resolution and TCP for API server communication. Misconfigured network policies that block UDP port 53 are a common cause of pod DNS failures.
---
Q6. How would you diagnose network connectivity issues between two services? [Mid]
Answer: I follow a layered approach: ping checks L3 reachability, telnet/nc checks L4 port connectivity, curl verifies L7 application response. I'd also check iptables/nftables rules, security groups, and run traceroute to identify where packets are dropping. For intermittent issues, tcpdump captures traffic for analysis.
Bonus point: In Kubernetes environments, mention using kubectl exec to test from within the pod's network namespace, and checking NetworkPolicy resources that might be silently dropping traffic.
---
Q7. What is the difference between /proc and /sys filesystems? [Mid]
Answer: /proc is a virtual filesystem exposing process and kernel information — each PID gets a directory with memory maps, file descriptors, and status. /sys exposes the device model and kernel subsystems in a structured hierarchy. Both are pseudo-filesystems that don't consume disk — they're interfaces to kernel data structures.
Bonus point: Mention that container runtimes mount modified /proc to hide host information, and that tools like cAdvisor read /sys/fs/cgroup to collect container resource metrics.
---
Q8. Explain how SSH tunneling works and when you'd use it in DevOps. [Mid]
Answer: SSH tunneling encapsulates traffic within an encrypted SSH connection. Local forwarding (-L) maps a local port to a remote service through the SSH server. Remote forwarding (-R) exposes a local service to the remote network. I use it to securely access RDS databases, internal dashboards, or Kubernetes API servers that aren't publicly exposed.
Bonus point: Mention SSH ProxyJump (-J) for chaining through bastion hosts, and how tools like sshuttle can create a poor-man's VPN for temporary access during incident response.
---
Q9. How do you configure Linux to forward traffic between interfaces (routing)? [Senior]
Answer: Enable IP forwarding with echo 1 > /proc/sys/net/ipv4/ip_forward (persist in /etc/sysctl.conf). Configure iptables NAT rules for masquerading outbound traffic. Add static routes with ip route add for specific destination networks. For production, I'd use a proper routing daemon like FRR or configure VPC route tables in cloud environments.
Bonus point: Explain that Kubernetes kube-proxy uses iptables or IPVS rules to implement Service routing, and that CNI plugins like Calico use BGP for pod-to-pod routing across nodes.
---
Q10. A server is performing poorly. Walk me through your full diagnostic process. [Senior]
Answer: I use the USE method (Utilization, Saturation, Errors) across resources. Start with uptime for load averages, vmstat 1 for CPU/memory/IO patterns, iostat -xz 1 for disk bottlenecks, and sar -n DEV 1 for network throughput. Check dmesg for kernel errors. For applications, examine open file descriptors (lsof), thread counts, and connection states (ss -s). Correlate timestamps with deployment events or traffic spikes.
Bonus point: Reference Brendan Gregg's performance checklist and mention that in cloud environments, you should also check instance credits (T-series instances), noisy neighbor effects, and hypervisor-level throttling that won't show in guest OS metrics.
---
2. Docker & Containers (Questions 11-18)
Q11. Explain multi-stage Docker builds and why they matter. [Junior]
Answer: Multi-stage builds use multiple FROM statements in a single Dockerfile. You compile code in a build stage with full tooling, then copy only the final artifact to a minimal runtime image. This dramatically reduces image size (often from 1GB+ to under 100MB), eliminates build tools from production images, and reduces the attack surface.
Bonus point: Show you understand the --from=builder syntax and mention that you can target specific stages with docker build --target=test to run tests without building the final production image.
---
Q12. What is the difference between CMD and ENTRYPOINT in a Dockerfile? [Junior]
Answer: ENTRYPOINT defines the executable that always runs — it sets the container's primary purpose. CMD provides default arguments that can be overridden at runtime. When used together, ENTRYPOINT is the command and CMD supplies default flags. For example, ENTRYPOINT ["nginx"] with CMD ["-g", "daemon off;"] lets users override just the arguments.
Bonus point: Mention the exec form ["binary", "arg"] vs shell form binary arg — shell form wraps in /bin/sh -c which prevents signal propagation, causing containers to not respond to SIGTERM gracefully during shutdown.
---
Q13. How does Docker networking work? Explain bridge, host, and overlay networks. [Mid]
Answer: Bridge (default) creates an isolated network with NAT — containers communicate via virtual bridge and reach external networks through iptables masquerading. Host mode removes network isolation, binding container ports directly to the host — useful for performance-sensitive workloads. Overlay networks span multiple Docker hosts using VXLAN encapsulation, enabling Swarm/multi-host communication without manual routing.
Bonus point: Mention that in Kubernetes, the CNI model differs from Docker — every pod gets a routable IP without NAT, and network plugins like Calico, Cilium, or Flannel implement this differently (BGP, eBPF, VXLAN respectively).
---
Q14. How do you reduce Docker image size in production? [Mid]
Answer: Start with a minimal base image (Alpine or distroless). Use multi-stage builds to exclude build tools. Combine RUN commands to reduce layers, clean package caches in the same layer (apt-get clean && rm -rf /var/lib/apt/lists/*). Use .dockerignore to prevent unnecessary files from entering the build context. Order layers by change frequency for better cache utilization.
Bonus point: Mention docker image history to analyze layer sizes, and that Google's distroless images contain only the application runtime with no shell or package manager — making them ideal for security-conscious production deployments.
---
Q15. Explain Docker volumes vs bind mounts. When do you use each? [Junior]
Answer: Volumes are managed by Docker and stored in /var/lib/docker/volumes/ — they persist independently of containers and are portable. Bind mounts map a host path directly into the container — great for development but create host-dependency. Named volumes are preferred for databases and stateful services; bind mounts are ideal for local development where you want live code reloading.
Bonus point: Mention tmpfs mounts for sensitive data that should never touch disk (like secrets during build), and that in production Kubernetes, you'd use PersistentVolumeClaims backed by cloud storage (EBS, EFS) instead of host-path volumes.
---
Q16. A container keeps restarting in a crash loop. How do you debug it? [Mid]
Answer: First, docker logs <container> reveals application errors. If it crashes too fast, docker run --entrypoint /bin/sh <image> lets me start a shell instead. Check resource limits — OOMKilled appears in docker inspect. Review docker events for real-time lifecycle events. For Kubernetes, kubectl describe pod shows restart reasons and kubectl logs --previous retrieves logs from the crashed instance.
Bonus point: Mention that adding --restart=no temporarily prevents restart loops during debugging, and that ephemeral containers in Kubernetes (kubectl debug) let you attach a debugging container to a running pod without modifying the image.
---
Q17. How do you handle secrets in Docker containers securely? [Senior]
Answer: Never bake secrets into images or pass via environment variables (they're visible in docker inspect). Use Docker Secrets (Swarm) or mount secrets from a vault at runtime. In CI/CD, use build-time secrets with --mount=type=secret in BuildKit so they don't persist in layers. In Kubernetes, use external-secrets-operator to sync from AWS Secrets Manager or HashiCorp Vault into native Secrets.
Bonus point: Mention that even Kubernetes Secrets are base64-encoded (not encrypted) by default. Enable etcd encryption at rest, use sealed-secrets for GitOps, and consider CSI Secret Store Driver for direct vault-to-pod injection without storing secrets in etcd.
---
Q18. Explain container resource limits and what happens when they're exceeded. [Mid]
Answer: CPU limits use CFS (Completely Fair Scheduler) throttling — containers get throttled but keep running. Memory limits are hard — exceeding them triggers the OOM killer, terminating the process immediately. I set requests (guaranteed minimum) and limits (maximum allowed) separately. Requests affect scheduling, limits enforce boundaries.
Bonus point: Warn about CPU throttling being invisible in metrics — a container might appear to use 50% CPU but actually be throttled 80% of the time. Check cpu.stat in cgroup for nr_throttled and throttled_time. This is a top cause of latency issues that don't show up in standard monitoring.
---
3. Kubernetes (Questions 19-28)
Q19. Explain the Kubernetes control plane components and their roles. [Junior]
Answer: The API Server is the frontend — all communication goes through it. etcd stores cluster state as a distributed key-value store. The Scheduler assigns pods to nodes based on resource requirements and constraints. The Controller Manager runs control loops (ReplicaSet, Deployment, Node controllers) that maintain desired state. Cloud Controller Manager handles provider-specific operations like load balancers and volumes.
Bonus point: Mention that the API Server is the only component that talks to etcd directly, and that you can run multiple API server instances behind a load balancer for high availability, but etcd requires careful quorum management (odd numbers: 3, 5, 7 nodes).
---
Q20. What happens when you run <code class="inline-code">kubectl apply -f deployment.yaml</code>? [Junior]
Answer: kubectl sends the manifest to the API Server, which validates it, persists to etcd, and returns success. The Deployment controller notices the new resource and creates a ReplicaSet. The ReplicaSet controller creates Pod objects. The Scheduler assigns pods to nodes. The kubelet on each node pulls the image, creates containers via the container runtime, and reports status back to the API server.
Bonus point: Mention that apply uses server-side apply with field management (tracking who owns which fields), enabling safe multi-tool management. Contrast with create (fails if exists) and replace (full object replacement that can drop fields).
---
Q21. How does Kubernetes handle rolling updates, and how would you rollback? [Mid]
Answer: Rolling updates are controlled by the Deployment's strategy — maxSurge defines how many extra pods can exist, maxUnavailable defines how many can be down. Kubernetes creates a new ReplicaSet, scales it up gradually while scaling the old one down. For rollback, kubectl rollout undo deployment/<name> reverts to the previous ReplicaSet. The history is retained based on revisionHistoryLimit.
Bonus point: Mention that you can rollback to a specific revision with --to-revision=N, and that combining rolling updates with readiness probes ensures traffic only routes to healthy pods. Progressive delivery tools like Argo Rollouts add canary analysis and automated rollback based on metrics.
---
Q22. Explain the difference between a DaemonSet, Deployment, and StatefulSet. [Mid]
Answer: Deployments manage stateless replicas — any pod is interchangeable. DaemonSets run exactly one pod per node (or selected nodes) — used for log collectors, monitoring agents, and CNI plugins. StatefulSets provide stable network identities, ordered deployment, and persistent storage — used for databases (MySQL, Kafka, etcd) where pod identity matters.
Bonus point: Mention that StatefulSets use headless Services for stable DNS (pod-0.service.namespace.svc.cluster.local) and that podManagementPolicy: Parallel can speed up scaling when order doesn't matter for your specific stateful workload.
---
Q23. A pod is stuck in Pending state. How do you troubleshoot? [Mid]
Answer: kubectl describe pod reveals the reason in Events. Common causes: insufficient cluster resources (CPU/memory requests exceed available capacity), no nodes match nodeSelector or affinity rules, PersistentVolumeClaim can't bind (no matching PV or StorageClass provisioner failing), or taints with no matching tolerations. Check kubectl get events --sort-by=.metadata.creationTimestamp for cluster-wide scheduling issues.
Bonus point: Mention that kubectl get nodes -o custom-columns=NAME:.metadata.name,CPU:.status.allocatable.cpu,MEM:.status.allocatable.memory helps identify if the cluster needs scaling, and that the Cluster Autoscaler adds nodes when pods are pending due to resource constraints.
---
Q24. How does Kubernetes DNS work? [Mid]
Answer: CoreDNS runs as a Deployment in the kube-system namespace and serves as the cluster DNS. Pods get a DNS search path configured in /etc/resolv.conf (typically <namespace>.svc.cluster.local, svc.cluster.local, cluster.local). Services get A records (my-svc.my-ns.svc.cluster.local), and headless Services get individual pod A records. External names use CNAME records.
Bonus point: Mention ndots:5 in resolv.conf means any name with fewer than 5 dots gets the search domains appended — this causes extra DNS lookups for external domains. Setting dnsPolicy: Default or reducing ndots can reduce DNS query volume significantly in high-throughput applications.
---
Q25. Explain Kubernetes NetworkPolicies. [Mid]
Answer: NetworkPolicies are firewall rules for pods — by default, all traffic is allowed. Once you apply a policy selecting certain pods, those pods default-deny all ingress/egress not explicitly allowed. Policies select pods via labels and define allowed sources/destinations by pod labels, namespace labels, or CIDR blocks. They require a CNI that supports them (Calico, Cilium, Weave — not Flannel by default).
Bonus point: Mention the "default deny all" pattern — applying an empty ingress/egress policy to a namespace locks everything down, then you whitelist specific flows. This is critical for compliance (PCI-DSS, SOC2) where you need to demonstrate network segmentation between workloads.
---
Q26. How do you implement horizontal pod autoscaling? [Mid]
Answer: HPA watches metrics (CPU, memory, or custom metrics) and adjusts replica count. Configure with kubectl autoscale deployment <name> --min=2 --max=10 --cpu-percent=70. It uses the metrics-server for resource metrics. For custom metrics (request rate, queue depth), use Prometheus Adapter or KEDA (Kubernetes Event-Driven Autoscaling) which supports scaling from external sources like SQS queues or Kafka topics.
Bonus point: Mention the stabilization window to prevent flapping (default 5min for scale-down), and that combining HPA with Cluster Autoscaler creates a fully elastic system — HPA adds pods, Cluster Autoscaler adds nodes when pods can't schedule.
---
Q27. How would you handle a noisy neighbor problem in a shared Kubernetes cluster? [Senior]
Answer: Implement ResourceQuotas per namespace to cap total resource consumption. Set LimitRanges to enforce per-pod minimums and maximums. Use PriorityClasses to ensure critical workloads get resources first during contention. For network isolation, apply NetworkPolicies. Consider dedicated node pools with taints/tolerations for latency-sensitive workloads, and use PodDisruptionBudgets to protect availability during node drains.
Bonus point: Discuss quality-of-service classes — Guaranteed (requests=limits) pods are last to be evicted. Burstable pods get evicted before Guaranteed but after BestEffort. This OOM-score based eviction is critical for multi-tenant clusters where you want to protect production workloads from development/staging resource spikes.
---
Q28. Design a zero-downtime migration strategy for a stateful service in Kubernetes. [Senior]
Answer: First, ensure the new version handles the existing data schema (backward compatibility). Use a blue-green approach with StatefulSets: deploy the new version alongside the old, replicate data, then switch traffic via Service selector update. For databases, use logical replication to sync during transition. Implement connection draining with preStop hooks and terminationGracePeriodSeconds. Validate with canary traffic before full cutover.
Bonus point: Mention the expand-and-contract pattern for schema migrations — expand (add new columns), deploy code that handles both formats, migrate data, then contract (remove old columns). This prevents any single deployment from being a point of failure and allows instant rollback.
---
4. CI/CD (Questions 29-35)
Q29. What makes a good CI/CD pipeline? Describe the stages. [Junior]
Answer: A good pipeline is fast, reliable, and provides clear feedback. Stages typically include: lint/format check, unit tests, build artifact, integration tests, security scanning (SAST/DAST), deploy to staging, smoke tests, and production deployment with canary or blue-green strategy. Each stage should fail fast — run quick checks first so developers get feedback in minutes, not hours.
Bonus point: Mention pipeline-as-code stored in version control alongside application code, and that effective pipelines have less than 10-minute feedback loops for the commit stage. Cache dependencies aggressively and parallelize test suites to achieve this.
---
Q30. Explain the difference between blue-green and canary deployments. [Junior]
Answer: Blue-green maintains two identical environments — deploy to inactive (green), test it, then switch traffic atomically. Rollback means switching back. Canary releases traffic gradually (1%, 5%, 25%, 100%) to the new version while monitoring error rates and latency. Canary catches issues that only appear under real traffic patterns. Blue-green is simpler but requires double the infrastructure during transition.
Bonus point: Mention that canary deployments pair well with feature flags — you can deploy code to 100% of pods but enable the feature for only 1% of users. Tools like Argo Rollouts automate canary progression with metric-based promotion gates.
---
Q31. How do you handle database migrations in a CI/CD pipeline? [Mid]
Answer: Database migrations run as a separate step before application deployment, using tools like Flyway or Liquibase for versioned schema changes. Every migration must be backward-compatible so the current running version works during deployment. I use a migration job (Kubernetes Job or pre-deploy hook) that runs idempotently. The pipeline fails and halts deployment if the migration fails.
Bonus point: Explain the expand-and-contract pattern — never drop columns or rename in one step. Add the new column, deploy code that writes to both, backfill data, deploy code that reads from new column, then remove the old. Each step is independently reversible.
---
Q32. How do you implement secrets management in CI/CD pipelines? [Mid]
Answer: Never store secrets in code or pipeline definitions in plain text. Use the platform's native secrets (GitHub Secrets, GitLab CI Variables marked protected/masked). For runtime, integrate with a vault (HashiCorp Vault, AWS Secrets Manager). Inject secrets at deploy-time, not build-time — this enables rotation without rebuilds. Audit access logs and rotate secrets automatically on a schedule.
Bonus point: Discuss OIDC federation — modern CI systems (GitHub Actions, GitLab) can assume cloud IAM roles directly without storing long-lived credentials, using short-lived tokens that expire after the pipeline run. This eliminates the biggest risk vector: leaked static credentials.
---
Q33. How would you design a CI pipeline for a monorepo with 20+ services? [Senior]
Answer: Implement path-based triggering — only build/test services whose files changed. Use tools like Nx, Turborepo, or Bazel for dependency-aware builds that understand the service graph. Cache aggressively (Docker layers, dependency downloads, test results). Parallelize across services that don't depend on each other. Use a shared pipeline template that each service extends, ensuring consistency while allowing customization.
Bonus point: Mention that change detection should include transitive dependencies — if a shared library changes, all services depending on it need rebuilding. Tools like Bazel's remote execution and remote caching can reduce a 45-minute pipeline to 5 minutes by only rebuilding the affected subgraph.
---
Q34. Explain GitOps and how it differs from traditional CI/CD. [Mid]
Answer: GitOps uses Git as the single source of truth for infrastructure and application state. An operator (ArgoCD, Flux) continuously reconciles cluster state with the Git repository — if they drift, the operator corrects it. Traditional CI/CD pushes changes; GitOps pulls them. This provides audit trails, easy rollbacks (git revert), and prevents configuration drift because no one makes manual changes.
Bonus point: Explain the pull-based model's security advantage — the cluster pulls from Git, so CI doesn't need cluster credentials. The deploy key only needs read access to the Git repo, dramatically reducing the blast radius of a compromised CI system.
---
Q35. A deployment failed in production. Walk me through your rollback strategy. [Senior]
Answer: First, assess impact — check error rates, latency, and user impact from monitoring. If severe, immediately rollback via kubectl rollout undo or revert the Git commit in a GitOps setup. Communicate the incident through status page and Slack. Then investigate: compare the failed deployment with the previous working version, check logs during the exact rollout window. Document findings in a post-mortem. Finally, add the failure scenario to CI tests to prevent recurrence.
Bonus point: Mention automated rollback gates — tools like Argo Rollouts and Flagger can automatically revert if error rates exceed SLO thresholds during the canary phase, catching issues before they reach 100% of traffic. Also discuss the importance of feature flags as a non-deploy rollback mechanism.
---
5. Terraform & IaC (Questions 36-40)
Q36. Explain Terraform state and why it matters. [Junior]
Answer: Terraform state is a JSON file that maps your configuration to real-world resources. It tracks resource IDs, dependencies, and metadata so Terraform knows what exists and what needs changing. Without state, Terraform can't determine what to create, update, or destroy. State must be stored remotely (S3 + DynamoDB, Terraform Cloud) for team collaboration with locking to prevent concurrent modifications.
Bonus point: Mention that state contains sensitive data (database passwords, private keys) and should be encrypted at rest. Never commit terraform.tfstate to Git. Use terraform state list and terraform state show for debugging, and terraform import to bring existing resources under management.
---
Q37. How do you structure Terraform code for a multi-environment setup? [Mid]
Answer: Use a modular structure: reusable modules in /modules define infrastructure patterns (VPC, EKS cluster, RDS), and environment directories (/environments/dev, /staging, /prod) call those modules with different variables. Each environment has its own state file and backend configuration. Use workspaces or separate directories — I prefer directories because they allow completely different configurations and independent state.
Bonus point: Discuss using Terragrunt for DRY configurations across environments — it wraps Terraform with inheritance, dependency management, and automatic backend configuration. For larger organizations, mention platform modules published to a private registry that product teams consume without understanding the underlying complexity.
---
Q38. What is Terraform drift, and how do you detect and handle it? [Mid]
Answer: Drift occurs when real infrastructure differs from what Terraform state records — caused by manual changes in the console, other tools modifying resources, or auto-scaling events. Detect it with terraform plan in CI (scheduled or on PR). Handle it by either importing the change into state (terraform import), reverting the manual change, or updating your code to match reality. Regular plan-only runs in CI catch drift early.
Bonus point: Mention tools like Driftctl or AWS Config rules for continuous drift detection, and that some drift is expected (Auto Scaling groups changing instance counts). Use lifecycle { ignore_changes } for fields you expect to change outside Terraform, like ASG desired count or tags managed by other systems.
---
Q39. How do you manage Terraform modules across multiple teams? [Senior]
Answer: Publish shared modules to a private Terraform registry (Terraform Cloud or a Git-based registry). Version modules semantically (v1.2.0) so consuming teams can pin versions and upgrade on their schedule. Enforce module standards with terraform-docs for documentation, automated validation in CI, and policy-as-code (Sentinel or OPA) to ensure compliance. Provide golden-path modules for common patterns (EKS cluster, RDS instance) that embed organizational best practices.
Bonus point: Discuss the module contract concept — each module has a clear interface (input variables, outputs) and encapsulates complexity. Teams should be able to deploy infrastructure by filling in variables without understanding the implementation. Break changes require major version bumps and migration guides, just like library APIs.
---
Q40. Your Terraform state file is corrupted or lost. How do you recover? [Senior]
Answer: If using remote state with versioning (S3 bucket versioning), restore the previous version. If not, list all resources from the cloud provider's console or CLI, then rebuild state using terraform import for each resource. This is manual and error-prone for large infrastructure. For critical environments, prevent this by enabling state file versioning, DynamoDB locking, and regular backups of the state file to a separate location.
Bonus point: Mention terraform state pull/push for emergency state manipulation, and that Terraform Cloud automatically versions every state change with full history. For disaster recovery planning, document all resource IDs externally so imports are possible without cloud console access. Some teams maintain a "state reconstruction runbook" for their most critical infrastructure.
---
6. AWS/Cloud (Questions 41-45)
Q41. Explain the difference between Security Groups and NACLs. [Junior]
Answer: Security Groups are stateful firewalls at the instance/ENI level — if you allow inbound traffic, the response is automatically allowed. NACLs are stateless at the subnet level — you must explicitly allow both inbound and outbound rules. Security Groups only have allow rules (implicit deny); NACLs have numbered allow and deny rules processed in order. Use Security Groups for instance-level control and NACLs as a subnet-level safety net.
Bonus point: Mention that Security Groups can reference other Security Groups as sources (e.g., allow inbound from the "web-sg" group), enabling dynamic rules that adapt as instances scale. This is more maintainable than hardcoding CIDR ranges and is a key pattern for microservices architectures in AWS.
---
Q42. How would you design a highly available application on AWS? [Mid]
Answer: Deploy across multiple Availability Zones (minimum 2, preferably 3). Use an Application Load Balancer for traffic distribution with health checks. Auto Scaling Groups maintain desired capacity and replace unhealthy instances. Managed databases with Multi-AZ (RDS) or global tables (DynamoDB). Store state externally (ElastiCache, S3) so instances are disposable. Use Route 53 health checks for DNS failover if multi-region.
Bonus point: Discuss the cell-based architecture pattern — deploy independent stacks per AZ that can operate autonomously. Mention blast radius reduction: AZ isolation means a single-AZ failure only impacts ~33% of capacity, and Auto Scaling replaces instances in healthy AZs. For mission-critical, discuss active-active multi-region with Global Accelerator.
---
Q43. How do you implement least-privilege IAM policies effectively? [Mid]
Answer: Start with AWS managed policies for initial development, then tighten using IAM Access Analyzer which analyzes CloudTrail logs to generate policies based on actual usage. Use conditions (source IP, MFA, time) to add context. Scope resources with ARNs rather than *. Separate human access (SSO with time-limited sessions) from machine access (IAM roles with specific actions). Review with iam:SimulatePrincipalPolicy before deploying.
Bonus point: Mention permission boundaries as guardrails — they set the maximum permissions an IAM entity can have, even if its policy grants more. This is powerful for delegated administration where teams manage their own IAM but can't escalate beyond the boundary. Also discuss SCPs (Service Control Policies) for organization-wide restrictions.
---
Q44. Your AWS bill increased 40% month-over-month. How do you investigate? [Senior]
Answer: Start with Cost Explorer filtered by service, then drill into the top service by linked account and usage type. Check for: unintentional resources left running (forgotten dev environments), traffic spikes (data transfer charges), right-sizing opportunities (oversized instances), and pricing model gaps (on-demand where Reserved/Savings Plans apply). Use AWS Cost Anomaly Detection for automated alerting and tag-based allocation to identify which team/project drove the increase.
Bonus point: Discuss establishing FinOps practices: mandatory resource tagging via SCPs, automated scheduling (stop dev environments at night), Spot instances for fault-tolerant workloads (60-90% savings), and Graviton migration for compute-bound services (20%+ better price-performance). Set up AWS Budgets with SNS alerts before costs spiral.
---
Q45. Design a secure VPC architecture for a three-tier web application. [Senior]
Answer: Three subnet tiers across multiple AZs: public subnets (ALB, NAT Gateway), private subnets (application servers, ECS/EKS), and isolated subnets (databases, no internet route). NAT Gateway in public subnets gives private subnets outbound internet access. Use VPC endpoints (Gateway for S3/DynamoDB, Interface for other services) to keep AWS API traffic off the internet. Security Groups restrict traffic between tiers; NACLs add subnet-level defense-in-depth.
Bonus point: Mention VPC Flow Logs sent to CloudWatch/S3 for network forensics, AWS PrivateLink for accessing third-party SaaS without internet exposure, and Transit Gateway for hub-and-spoke connectivity between VPCs. For compliance, discuss no public IPs on any compute resource — all inbound traffic flows through ALB/CloudFront, all outbound through NAT with logging.
---
7. Monitoring & Observability (Questions 46-50)
Q46. Explain the three pillars of observability. [Junior]
Answer: Metrics are numeric measurements aggregated over time (CPU usage, request rate, error count) — good for dashboards and alerting. Logs are discrete events with context (timestamps, error messages, request IDs) — good for debugging specific issues. Traces follow a request across services, showing latency breakdown and dependency paths — essential for distributed system debugging. Together, they answer: "what's happening?" (metrics), "why?" (logs), and "where?" (traces).
Bonus point: Mention the emerging fourth pillar — continuous profiling (tools like Pyroscope, Grafana Phlare) that shows which code paths consume CPU/memory in production. Also discuss OpenTelemetry as the vendor-neutral standard for instrumenting all three pillars with a single SDK, avoiding vendor lock-in.
---
Q47. How do you define good SLOs and create actionable alerts? [Mid]
Answer: SLOs are defined from the user's perspective — "99.9% of API requests complete under 500ms" not "CPU stays below 80%." Measure with SLIs (Service Level Indicators) from real user traffic. Alert on error budget burn rate (how fast you're consuming your allowed downtime) rather than raw thresholds. A 1% error rate might be fine for a 99% SLO but emergency-level for a 99.99% SLO. Multi-window, multi-burn-rate alerts reduce noise while catching real issues.
Bonus point: Discuss the difference between symptom-based (user-impacting) and cause-based (CPU high) alerts. Prefer symptoms for paging — page when users are affected, not when a metric crosses an arbitrary threshold. Use cause-based metrics for debugging dashboards only. Reference Google's SRE book approach: 2% budget consumed in 1 hour = page, 5% in 6 hours = ticket.
---
Q48. A service is experiencing intermittent latency spikes. How do you investigate? [Mid]
Answer: Check if it correlates with time (cron jobs, traffic patterns) or specific endpoints. Look at percentile metrics (p99 vs p50) — high p99 with normal p50 suggests a subset of requests are slow. Examine traces for the slow requests to identify which service/dependency adds latency. Check for garbage collection pauses, connection pool exhaustion, database lock contention, or external dependency timeouts. Compare with deployment timeline for recent changes.
Bonus point: Mention the importance of percentile distributions over averages — an average of 100ms can hide that 1% of requests take 5 seconds. Discuss head-of-line blocking in HTTP/1.1, TCP retransmissions, and infrastructure-level causes like noisy neighbor (shared databases) or DNS resolution delays (the ndots problem in Kubernetes).
---
Q49. How do you implement centralized logging for a microservices architecture? [Mid]
Answer: Use structured logging (JSON) with consistent fields across services (request-id, service-name, timestamp, severity). Ship logs via a lightweight agent (Fluent Bit, Vector) to a centralized platform (Elasticsearch/OpenSearch, Loki, or CloudWatch Logs). Enrich logs with correlation IDs propagated through headers so you can trace a request across all services. Define retention policies by environment — production longer than dev.
Bonus point: Discuss log-based alerting for critical patterns (OOMKilled, panic, auth failures) and the cost implications of logging volume. Mention sampling strategies for high-throughput services — log 100% of errors but only 1% of success requests. Loki's label-based approach is more cost-effective than full-text indexing for most DevOps use cases.
---
Q50. Design a monitoring strategy for a production Kubernetes cluster from scratch. [Senior]
Answer: Layer the monitoring: infrastructure (node CPU, memory, disk, network), Kubernetes (pod status, restart counts, scheduling failures, API server latency), application (request rate, error rate, duration — RED method), and business (orders processed, user signups). Use Prometheus with kube-state-metrics and node-exporter for cluster telemetry. Grafana for dashboards organized by service team. AlertManager with PagerDuty/Opsgenie integration using routing rules based on severity and owning team.
Bonus point: Discuss the monitoring pyramid: broad infrastructure monitoring with low noise, targeted application monitoring with SLO-based alerting, and synthetic monitoring (probes that simulate user journeys) for end-to-end validation. Mention that alerting without runbooks is useless — every alert should link to a playbook describing: what the alert means, how to verify the issue, and steps to resolve. Implement alert quality reviews quarterly to prune noisy alerts that get ignored.
---
Final Interview Tips
Good luck with your interviews. Practice explaining these concepts out loud — writing answers and speaking them are very different skills.
---
Frequently Asked Questions
What are the most common DevOps interview questions?
Interviewers typically ask about CI/CD pipeline design, container orchestration with Kubernetes, infrastructure as code with Terraform, monitoring and observability strategies, and incident response processes. Expect scenario-based questions like "How would you handle a production outage?" and hands-on tasks involving Docker, Kubernetes, or scripting.
How do I prepare for a DevOps engineer interview?
Build and document real projects covering CI/CD, Kubernetes, Terraform, and monitoring. Practice explaining your architecture decisions and troubleshooting methodology. Review Linux fundamentals (networking, processes, filesystem), cloud services (AWS/Azure/GCP), and be ready to whiteboard system designs. Lab practice matters more than memorizing answers.
What is the difference between a DevOps engineer and an SRE?
DevOps engineers focus on building CI/CD pipelines, automation, and developer productivity tools across the software delivery lifecycle. SREs (Site Reliability Engineers) focus on production reliability through SLOs, error budgets, incident management, and capacity planning. In practice, roles overlap significantly and job descriptions vary by company.
What salary should I expect as a DevOps engineer?
DevOps engineer salaries vary by location, experience, and company size. In the US, junior roles start at $80-100K, mid-level at $120-160K, and senior/staff positions at $160-220K+. Remote roles and FAANG companies trend higher. Skills in Kubernetes, Terraform, and cloud architecture command premium compensation.