DevOps Engineer Interview Questions 2026

Sample Answer

Docker is a containerization platform that packages applications with their dependencies into portable containers. Kubernetes is a container orchestration platform that manages, scales, and maintains containerized applications across clusters. Use Docker alone for development environments, simple single-host deployments, and CI/CD build stages. Use Kubernetes when you need auto-scaling, self-healing, rolling updates, service discovery, and load balancing across multiple hosts. For smaller workloads, consider Docker Compose or AWS ECS. Kubernetes adds operational complexity that is only justified at scale. Managed Kubernetes services like EKS, GKE, and AKS reduce the operational burden significantly.

Sample Answer

Pipeline stages: (1) Source: trigger on git push with branch-based workflows (feature, develop, main). (2) Build: parallel builds for each microservice with dependency caching. (3) Test: unit tests, integration tests, contract tests between services. (4) Security: SAST scanning, dependency vulnerability checks, container image scanning. (5) Build artifacts: Docker image build, push to registry with semantic versioning and git SHA tags. (6) Deploy to staging: automated deployment, smoke tests, integration verification. (7) Deploy to production: canary or blue-green deployment with automated rollback on metric degradation. Use GitOps (ArgoCD/Flux) for declarative deployments. Implement pipeline-as-code in the repository. Add monitoring alerts for deployment failures.

Sample Answer

Infrastructure as Code manages infrastructure through declarative configuration files instead of manual processes, enabling version control, peer review, automated testing, and reproducible environments. Terraform is cloud-agnostic, uses HCL language, maintains state files, and supports a vast provider ecosystem including multi-cloud deployments. CloudFormation is AWS-native, deeply integrated with AWS services, requires no state management (AWS manages it), and supports drift detection. Choose Terraform for multi-cloud environments and team familiarity. Choose CloudFormation for AWS-only shops wanting tight integration and native support. Both support modules for reusable infrastructure patterns. Always use remote state storage (S3, Terraform Cloud) and state locking for team collaboration.

Sample Answer

Three main strategies: Blue-Green deployment maintains two identical environments; route traffic to the new one after verification, keeping the old one as instant rollback. Rolling update gradually replaces old instances with new ones, maintaining service availability throughout. Canary deployment routes a small percentage of traffic (1-5%) to the new version, monitors key metrics, and gradually increases traffic if healthy. In Kubernetes, use rolling update strategy with proper readiness and liveness probes. Set maxSurge and maxUnavailable appropriately. Implement health checks that verify application readiness, not just port availability. Add automated rollback triggers based on error rate, latency, and business metrics.

Sample Answer

Containers use network namespaces for isolation. Docker provides bridge networks (default, containers communicate via IP), host networks (container shares host network stack, no isolation), overlay networks (multi-host communication for Docker Swarm), and none (no networking). In Kubernetes, every pod gets a unique IP address. Pods communicate directly without NAT. Services provide stable DNS names and load balancing across pod replicas. Ingress controllers handle external traffic routing. Network policies control pod-to-pod communication for security. Service mesh (Istio, Linkerd) adds mTLS encryption, traffic management, and observability. Understanding CNI plugins (Calico, Cilium, Flannel) is important for troubleshooting network issues in production.

Sample Answer

Implement the four golden signals: latency (request duration), traffic (request rate), errors (error rate), and saturation (resource utilization). Use Prometheus for metrics collection and Grafana for dashboards. Implement structured logging with ELK stack or Loki. Use distributed tracing (Jaeger, OpenTelemetry) for request flow across services. Design alerts with clear ownership, actionable runbooks, and appropriate severity levels. Avoid alert fatigue by eliminating noisy alerts and using multi-condition triggers. Implement SLOs and error budgets to make reliability measurable. Monitor both infrastructure (CPU, memory, disk, network) and application metrics (response time, error rate, queue depth, cache hit rate). Use anomaly detection for unknown-unknowns.

Sample Answer

Vertical scaling (scaling up) adds more resources (CPU, RAM) to an existing instance. It is simpler, requires no application changes, but has hardware limits and creates a single point of failure. Horizontal scaling (scaling out) adds more instances behind a load balancer. It provides better fault tolerance and near-unlimited scaling but requires stateless application design, distributed session management, and database considerations. Use vertical scaling for databases (before sharding), legacy applications that cannot be easily distributed, and when quick scaling is needed. Use horizontal scaling for web servers, microservices, and any stateless workload. Most production systems combine both: vertically scale individual instances to a cost-effective point, then scale horizontally.

Sample Answer

Never store secrets in code, environment variables in plain text, or Docker images. Use a dedicated secrets manager: AWS Secrets Manager, HashiCorp Vault, or Azure Key Vault. Implement least-privilege access: each service gets only the secrets it needs. Rotate secrets automatically with zero downtime using the rotation lifecycle pattern. In Kubernetes, use external-secrets-operator to sync secrets from Vault or AWS Secrets Manager into Kubernetes Secrets (encrypted at rest with KMS). For CI/CD, use pipeline-native secret variables (GitHub Actions secrets, GitLab CI variables) that are masked in logs. Audit all secret access with logging. Never log sensitive values, and scan code repositories with tools like gitleaks to detect accidentally committed secrets.

Sample Answer

Shift-left security integrates security testing early in the development lifecycle rather than as a final gate. In CI/CD: run SAST (Static Application Security Testing) tools like SonarQube or Semgrep on every pull request. Scan dependencies for known vulnerabilities using Snyk or Dependabot. Scan container images with Trivy or Grype before pushing to registry. Implement infrastructure-as-code security scanning with Checkov or tfsec. Run DAST (Dynamic Application Security Testing) in staging environments. Use policy-as-code (OPA/Rego) to enforce security standards on Kubernetes manifests. Secrets detection with gitleaks prevents accidental credential exposure. Make security checks blocking for critical findings and advisory for medium ones to balance velocity with safety.

Sample Answer

GitOps uses Git as the single source of truth for both application code and infrastructure configuration. A GitOps operator (ArgoCD, Flux) continuously reconciles the desired state in Git with the actual state in the cluster, automatically applying changes and reverting drift. Compared to traditional push-based CI/CD where pipelines deploy directly to targets, GitOps is pull-based: the cluster pulls changes from Git. Benefits: full audit trail via Git history, easy rollback (git revert), consistent environments (what is in Git is what is running), and reduced blast radius (changes go through pull request review). GitOps works best with Kubernetes but the principles apply broadly. Combine with sealed-secrets or external-secrets for managing sensitive configuration.

Sample Answer

Define RTO (Recovery Time Objective) and RPO (Recovery Point Objective) based on business requirements. Strategy tiers: backup and restore (hours RTO, cheapest), pilot light (minutes to hours RTO, minimal infrastructure running), warm standby (minutes RTO, scaled-down replica), and multi-site active-active (near-zero RTO, most expensive). Implement automated backups with tested restore procedures. Use infrastructure as code for rapid environment recreation. Replicate data across regions (S3 cross-region replication, database read replicas). Document and automate runbooks for failover procedures. Conduct regular disaster recovery drills (gamedays) to verify procedures work under pressure. Monitor backup health and test restores monthly. DR planning without testing is just documentation.

Sample Answer

Liveness probes determine if a container is running. If a liveness probe fails, Kubernetes restarts the container. Use for detecting deadlocked applications or processes that are running but not functioning. Readiness probes determine if a container is ready to receive traffic. If a readiness probe fails, the pod is removed from service load balancing but not restarted. Use for applications that need initialization time or are temporarily unable to serve (database connection pool exhausted). Configure appropriate initialDelaySeconds to avoid killing pods during startup. Use HTTP probes for web services, TCP probes for databases, and exec probes for custom health checks. Misconfigured probes are a top cause of unnecessary pod restarts and cascading failures.

Sample Answer

Docker volumes are managed by Docker, stored in Docker's storage area (/var/lib/docker/volumes), and are the preferred mechanism for persisting data. They are portable across containers, can be named for easy reference, support volume drivers for remote storage (NFS, cloud), and Docker manages their lifecycle. Bind mounts map a host directory or file directly into the container, providing direct access to the host filesystem. Use volumes for persistent application data (databases, uploads). Use bind mounts for development (source code hot-reloading) and configuration files. Named volumes survive container removal and can be backed up. Both can be read-only for security. In Kubernetes, use PersistentVolumes and PersistentVolumeClaims instead.

Sample Answer

Ansible is agentless (SSH-based), uses YAML playbooks, has a low learning curve, and is ideal for ad-hoc tasks and smaller environments. Chef uses Ruby-based recipes with a client-server model, excels at complex configurations, and is popular in enterprise environments. Puppet uses its own declarative language with a client-server model, strong enforcement of desired state, and excellent reporting. In 2026, Ansible dominates for its simplicity and agentless architecture. However, container orchestration (Kubernetes) and IaC tools (Terraform) have replaced much of what configuration management tools used to do. Use configuration management for server setup and application configuration, IaC for infrastructure provisioning, and container orchestration for application deployment.

Sample Answer

Use a migration tool (Flyway, Liquibase, Alembic, Prisma Migrate) that tracks applied migrations with version numbers. Store migrations in version control alongside application code. Run migrations as a separate step before application deployment. Design migrations to be backward-compatible: add new columns as nullable, use expand-contract pattern for schema changes, and avoid dropping columns until all application versions stop referencing them. In Kubernetes, use init containers or migration jobs that run before the main application starts. Test migrations against production-like data in staging. Always have a rollback migration ready. For large tables, use online schema change tools (pt-online-schema-change, gh-ost) to avoid locking.

Sample Answer

A service mesh is an infrastructure layer that handles service-to-service communication in a microservices architecture. It provides: mTLS encryption (zero-trust security), traffic management (canary deployments, circuit breaking, retries), and observability (distributed tracing, metrics, access logs) without requiring application code changes. Popular implementations include Istio and Linkerd. Implement a service mesh when you have 10+ microservices and need consistent security, traffic management, and observability across all services. Do not implement it for monoliths or small microservice deployments: the operational complexity outweighs the benefits. Consider Linkerd for simplicity or Istio for feature completeness. Evaluate the latency and resource overhead before adoption.