Senior DevOps Engineer Interview Preparation Guide for Microsoft

DevOps Engineer

Microsoft

Senior

7 rounds

Updated 6/12/2026

Microsoft's interview process for Senior DevOps Engineers typically consists of an initial recruiter screening, followed by 1-2 technical phone screens, and 4-5 onsite interview rounds. The process emphasizes hands-on infrastructure expertise, system design thinking, incident response capability, and cultural alignment with Microsoft's engineering values. Senior-level candidates are expected to demonstrate deep technical proficiency, project ownership experience, and the ability to influence team direction through thoughtful architectural decisions.

Interview Rounds

Recruiter Screening

25 min3 focus topicsculture fit

Technical Phone Screen (Round 1)

50 min5 focus topicstechnical

What to Expect

First technical interview conducted by a senior DevOps engineer or SRE (45-60 minutes). This round typically covers a mix of conceptual questions about infrastructure design, CI/CD pipeline architecture, and troubleshooting scenarios. You may be asked to explain how you would solve a real-world infrastructure problem or discuss your approach to designing a scalable deployment system. Some interviewers may ask coding/scripting questions (bash, Python) to assess automation skills.

Tips & Advice

Think deeply about infrastructure tradeoffs (cost vs. complexity, scalability vs. operational overhead). When discussing solutions, explain your reasoning: why did you choose Kubernetes over ECS? Why use Terraform over CloudFormation? Reference specific metrics (deployment frequency, lead time for changes, error rates) when discussing monitoring. If asked a scenario, structure your response: 1) clarify requirements, 2) propose architecture, 3) discuss monitoring/alerting, 4) address disaster recovery. Use the whiteboard or shared document to sketch diagrams. For scripting questions, write clean, readable code with error handling; explain what you're doing as you code.

Focus Topics

Cloud Platform Architecture (Azure, AWS, or GCP)

Understanding of cloud service models (IaaS, PaaS, SaaS), networking (VPCs, subnets, security groups), compute options (VMs, containers, serverless), and database services. Discuss when to use each service.

Practice Interview

Study Questions

Troubleshooting Infrastructure and Application Issues

Systematic debugging approach for common issues: pods not starting, services unreachable, deployment failures, latency spikes. Use diagnostic tools (kubectl logs, journalctl, tcpdump) and walk through your investigation process.

Practice Interview

Study Questions

Container Orchestration (Kubernetes) Fundamentals

Core Kubernetes concepts: pods, services, deployments, namespaces, and RBAC. Discuss how you would scale applications, manage networking, and handle persistent storage in Kubernetes.

Practice Interview

Study Questions

Infrastructure as Code (Terraform, CloudFormation, ARM Templates)

Explain how you structure IaC projects, manage state, handle drift, version control, and apply configurations across multiple environments. Discuss state management challenges and solutions.

Practice Interview

Study Questions

CI/CD Pipeline Design and Implementation

Design a complete CI/CD pipeline for a multi-service application covering build, test, deploy, and rollback across dev/staging/prod environments. Address automated testing strategies, deployment validation, and rollback procedures.

Practice Interview

Study Questions

Technical Phone Screen (Round 2)

50 min5 focus topicstechnical

What to Expect

Second technical interview with a different senior engineer or team member (45-60 minutes). This round often digs deeper into a specific area skipped in Round 1, or covers additional technical domains such as monitoring/observability, secrets management, security practices, or infrastructure reliability patterns. You may be given a scenario involving incident response, designing a monitoring solution, or architecting a complex infrastructure migration.

Tips & Advice

In this round, expect deeper technical questions requiring nuanced understanding. If asked about monitoring, discuss SLOs/SLIs, alerting strategies, and observability. For secrets management, cover the full lifecycle from development to production (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault). If an incident scenario is presented, demonstrate blameless postmortem thinking: focus on systems, not blame; discuss root causes and systemic improvements. For infrastructure reliability, reference chaos engineering, canary deployments, and disaster recovery strategies. Show that you think holistically about infrastructure: not just 'does it work?' but 'is it resilient, observable, and cost-effective?'

Focus Topics

Scripting and Automation (Python, Bash, Go)

Write or discuss scripts for common infrastructure tasks: health checks, auto-remediation, infrastructure provisioning, log parsing. Demonstrate clean coding practices, error handling, and testability.

Practice Interview

Study Questions

Incident Response and Blameless Postmortems

Walk through your incident response process: detection, triage, mitigation, diagnosis, communication, and post-incident review. Discuss how you approach postmortems to identify systemic issues rather than individual failures.

Practice Interview

Study Questions

Secrets Management and Security Best Practices

How to securely manage credentials and secrets across development, CI/CD, and production environments. Cover tools (Vault, AWS Secrets Manager), rotation strategies, audit logging, and compliance (HIPAA, PCI-DSS if relevant).

Practice Interview

Study Questions

Infrastructure Reliability and Disaster Recovery

Strategies for high availability: multi-region failover, backup and restore procedures, RTO/RPO planning, chaos engineering, and testing disaster recovery plans.

Practice Interview

Study Questions

Monitoring, Observability, and Alerting Strategy

Design a monitoring and alerting system for a critical application. Cover metrics collection (Prometheus, Datadog), logging (ELK, Azure Monitor), tracing, SLOs/SLIs/error budgets, and alert routing to on-call engineers.

Practice Interview

Study Questions

Onsite Interview - Infrastructure System Design

75 min5 focus topicssystem design

What to Expect

Full infrastructure design round (60-90 minutes) where you design a complete architecture for a given application or scenario. You'll be asked to design infrastructure for a SaaS application serving global traffic, a microservices architecture, a migration from monolith to containers, or a scalable platform for internal developer teams. You are expected to draw architecture diagrams, discuss specific cloud services and their configuration, estimate costs, and defend trade-offs. This round emphasizes your ability to see the 'big picture' and make sound architectural decisions balancing reliability, cost, and operational complexity.

Tips & Advice

Start by clarifying requirements: scale (QPS, data volume), traffic patterns, latency requirements, availability targets (SLA), and compliance constraints. Propose a layered architecture: compute (Kubernetes, serverless), networking (CDN, load balancers), data (databases, caches, storage), and observability. Discuss how each component scales and fails. For senior-level, interviewers expect you to discuss trade-offs explicitly: why multi-region vs. single region? Why managed services vs. self-managed? Why Kubernetes complexity for this workload? Estimate costs roughly and discuss optimization strategies. Draw clear diagrams showing data flow, security boundaries, and failover paths. Discuss disaster recovery: RPO/RTO, backup strategy, failover automation. Address security: encryption, RBAC, network segmentation. Mention tools and specific cloud services by name (not generic 'compute' but 'Azure Kubernetes Service' or 'AWS ECS on EC2'). Prepare to justify every architectural decision.

Focus Topics

Capacity Planning and Performance Optimization

Load testing methodologies, identifying bottlenecks, resource allocation decisions, and optimization strategies for latency, throughput, and cost.

Practice Interview

Study Questions

Networking, Security, and Compliance in Infrastructure Design

Network architecture (VPCs, subnets, NACLs, security groups), encryption (in-transit, at-rest), identity management (IAM), and compliance requirements (data residency, audit logging).

Practice Interview

Study Questions

Cloud Service Selection and Cost Optimization

Compare compute options (VMs, containers, serverless), storage types, database choices. Discuss cost drivers, reserved capacity, auto-scaling, and cost optimization strategies.

Practice Interview

Study Questions

Distributed System Architecture and Design Patterns

Design patterns for resilient distributed systems: microservices, service mesh (Istio, Linkerd), event-driven architecture, API gateways, and circuit breakers. Discuss when each pattern is appropriate.

Practice Interview

Study Questions

Multi-Region and High-Availability Architecture

Design strategies for global deployments: multi-region failover, active-active vs. active-passive, data replication, DNS routing, and handling partition tolerance.

Practice Interview

Study Questions

Onsite Interview - Kubernetes Deep Dive and Container Orchestration

65 min5 focus topicstechnical

What to Expect

Technical deep dive into container orchestration and Kubernetes (60-75 minutes). This round covers Kubernetes architecture, cluster design, networking (CNI plugins), storage (StatefulSets, persistent volumes), security (RBAC, network policies), and operations (upgrades, scaling, debugging). You may be asked to design a Kubernetes cluster for a specific workload, troubleshoot pod issues, or discuss advanced topics like custom resource definitions (CRDs) and operators. The interviewer expects you to understand Kubernetes deeply and make informed decisions about cluster architecture.

Tips & Advice

Demonstrate hands-on Kubernetes knowledge: namespaces, resource quotas, pod disruption budgets, ingress controllers, and storage provisioners. When discussing cluster design, address node sizing, networking model (overlay vs. host), CNI choice, and upgrade strategy. For troubleshooting, use systematic debugging: describe nodes, pod status, events, logs, and metrics. Show understanding of when Kubernetes is appropriate vs. when simpler solutions (serverless, managed services) are better. Discuss operational concerns: RBAC policies, network policies for security, resource limits to prevent noisy neighbor problems, and monitoring cluster health. For senior-level, discuss architectural decisions: self-managed vs. managed Kubernetes (AKS, EKS), single cluster vs. multi-cluster strategy, GitOps deployment patterns. Reference real-world Kubernetes challenges (etcd backup, certificate management, version upgrades).

Focus Topics

Kubernetes Storage and Stateful Workloads

Storage provisioners, persistent volumes, persistent volume claims, StatefulSets for databases/caches, data replication, and backup strategies for stateful applications.

Practice Interview

Study Questions

Troubleshooting and Operations

Debugging pod failures (CrashLoopBackOff, ImagePullBackOff, pending), node issues, cluster scaling, upgrade procedures, and monitoring cluster health.

Practice Interview

Study Questions

Kubernetes Networking and Service Mesh

Pod networking, service types (ClusterIP, NodePort, LoadBalancer), ingress controllers, network policies for security, DNS, and service mesh concepts (traffic management, security, observability).

Practice Interview

Study Questions

Kubernetes Security (RBAC, Network Policies, Pod Security)

Role-based access control (RBAC), network policies, pod security standards, secrets management in Kubernetes, and compliance considerations.

Practice Interview

Study Questions

Kubernetes Cluster Architecture and Design

Design a Kubernetes cluster: control plane setup, worker node sizing, networking (CNI plugins), storage provisioning, and upgrade strategy. Discuss managed vs. self-managed Kubernetes.

Practice Interview

Study Questions

Onsite Interview - Infrastructure as Code and GitOps

65 min5 focus topicstechnical

What to Expect

Deep dive into infrastructure as code practices, configuration management, and GitOps workflows (60-75 minutes). You'll discuss Terraform/CloudFormation/ARM Templates, state management, module design, testing infrastructure code, and GitOps deployment patterns (ArgoCD, Flux). Expect questions about how you structure IaC projects across teams, handle secrets in version control, automate infrastructure testing, and maintain consistency across environments. This round assesses your ability to make infrastructure reproducible, versionable, and auditable.

Tips & Advice

For IaC tools (Terraform, CloudFormation, ARM), discuss module design: how do you structure modules for reusability? How do you handle dependencies? Show understanding of state management challenges: shared state, remote backends, state locking, and disaster recovery (state loss recovery). Discuss testing strategies: static analysis (tflint), plan validation, and integration tests. For GitOps, explain the benefits: GitOps as single source of truth, automated drift detection, auditable changes, and rollback via Git. Discuss trade-offs: GitOps for deployment but not infrastructure provisioning? Or end-to-end GitOps? Address secrets: never commit secrets to Git; discuss secret injection patterns (external secrets, sealed secrets, Vault integration). For senior-level, discuss scaling IaC across teams: code review processes, module governance, cost estimation, and compliance scanning. Reference specific tools and share how you've structured projects.

Focus Topics

Configuration Management and Policy as Code

Configuration management tools (Ansible), infrastructure testing, and policy enforcement (Terraform Cloud, Sentinel, conftest). Discuss cost estimation and compliance scanning.

Practice Interview

Study Questions

Secrets Management in Infrastructure Code

Preventing secrets in version control, injecting secrets into IaC at runtime, HashiCorp Vault integration, cloud-native secrets (Azure Key Vault, AWS Secrets Manager).

Practice Interview

Study Questions

GitOps and Declarative Infrastructure Management

GitOps principles, tools (ArgoCD, Flux), benefits (single source of truth, drift detection, audit trail), and challenges (secrets management, secrets in Git). Discuss when to use GitOps for infrastructure vs. applications.

Practice Interview

Study Questions

State Management and Multi-Team IaC Governance

Managing Terraform state across teams, handling concurrent changes, state locking, disaster recovery, and implementing governance (module standards, approval processes, cost controls).

Practice Interview

Study Questions

Terraform and Infrastructure as Code Best Practices

Terraform project structure, modules, remote state management (backends, locking, secrets), testing strategies (terraform plan validation, tflint), and versioning.

Practice Interview

Study Questions

Onsite Interview - Behavioral and Incident Response

55 min5 focus topicsbehavioral

What to Expect

Behavioral and culture fit interview (45-60 minutes) with a senior engineer or manager focused on soft skills, decision-making, collaboration, and how you handle challenges. Expect questions about past projects, conflict resolution, mentoring, and your approach to learning. You'll also discuss incident response and on-call philosophy: how you've handled production incidents, your post-mortem process, and how you balance speed and safety in deployments. This round evaluates how you work with cross-functional teams, handle pressure, and contribute to team culture.

Tips & Advice

Use the STAR method (Situation, Task, Action, Result) for behavioral questions. Prepare stories about infrastructure projects you owned, challenges you overcame, and lessons learned. When discussing incidents, emphasize blameless postmortem culture: focus on systems, not individual blame. Share specific metrics: reduced deployment lead time from X to Y, decreased mean time to recovery (MTTR), or improved system availability. Discuss how you stayed current with evolving technologies and when you chose not to adopt a new tool. Talk about mentoring junior team members and how you've helped them grow. For Microsoft fit, research their engineering culture, diversity and inclusion initiatives, and how your values align. Ask thoughtful questions about team structure, infrastructure challenges, and growth opportunities. Show genuine enthusiasm for solving infrastructure problems, not just working with cool tools.

Focus Topics

Mentoring and Technical Leadership

Describe how you've mentored junior engineers, transferred knowledge, or improved team practices. What guidance do you give when team members face infrastructure challenges?

Practice Interview

Study Questions

Learning and Staying Current

How do you stay current with infrastructure trends? Discuss a technology you learned recently and why. When did you decide NOT to adopt a popular tool and why?

Practice Interview

Study Questions

Cross-Functional Collaboration and Communication

How do you work with software engineers, database administrators, security teams, and management? Give examples of collaborating across teams, handling disagreements, and aligning on priorities.

Practice Interview

Study Questions

Incident Response and On-Call Maturity

Walk through a production incident: detection, triage, mitigation, diagnosis, communication, and post-mortem. Discuss your approach to on-call responsibilities, escalation procedures, and how you prevent recurrence.

Practice Interview

Study Questions

Project Ownership and Infrastructure Decision-Making

Discuss a major infrastructure project you owned: what was the problem, how did you approach it, what technologies did you choose and why, what trade-offs did you make, and what was the outcome?

Practice Interview

Study Questions

Frequently Asked DevOps Engineer Interview Questions

Kubernetes and Container Orchestration FundamentalsMediumTechnical

99 practiced

Describe how you would roll back a failed Deployment rollout and how to inspect rollout history. Include the kubectl commands and explain any caveats when rolling back a Deployment that changes ConfigMaps, Secrets, or persistent storage.

Sample Answer

Brief approach- Inspect history and status, identify failing revision, then rollback using kubectl while validating pods and related resources (ConfigMaps/Secrets/PVs).

Commands and workflow- Check rollout status:

bash

kubectl rollout status deployment/my-app -n prod

- View rollout history (revisions and change-cause if set):

bash

kubectl rollout history deployment/my-app -n prod
kubectl rollout history deployment/my-app --revision=3 -n prod

- Roll back to previous revision:

bash

kubectl rollout undo deployment/my-app -n prod

- Roll back to a specific revision:

bash

kubectl rollout undo deployment/my-app --to-revision=2 -n prod

- Verify new rollout and pod readiness:

bash

kubectl get rs -l app=my-app -n prod
kubectl describe rs <replica-set> -n prod
kubectl get pods -l app=my-app -n prod
kubectl rollout status deployment/my-app -n prod

Key checks & caveats (important for DevOps)- ConfigMaps/Secrets: Deployment revision captures pod template refs (name) but not ConfigMap/Secret contents. If a rollback returns pods that reference a ConfigMap/Secret that was changed, you may still be running with the latest data. To ensure config matches revision, either: - Version ConfigMaps/Secrets (e.g., my-config-v2) and reference the appropriate named resource in the Deployment; or - After rollback, restart pods to pick up an older config or re-create the ConfigMap/Secret to match desired content and then rollout restart.- Persistent storage: Rolling back a Deployment does not revert persistent volumes. Data stateful changes are not undone—be cautious; use backups/snapshots if you need data rollback. For stateful workloads prefer StatefulSet and explicit data migration plans.- Image tags: Avoid mutable tags like :latest; use immutable image digests/tags so rollbacks reliably restore prior code.- Change-cause and audits: Use kubectl annotate or --record (deprecated) to capture change-cause for easier history inspection.

Validation- Monitor logs and health checks after rollback:

bash

kubectl logs -l app=my-app -n prod
kubectl describe pod <pod> -n prod

This ensures the rollback restored a healthy state and that config/data alignment is correct.

Kubernetes TroubleshootingEasyTechnical

93 practiced

What commands and metrics do you check to assess node health and kubelet status when pods are failing on a single node? Include how you would inspect systemd logs, kubelet logs, container runtime status, node conditions (Ready, DiskPressure, MemoryPressure) and relevant kubectl commands.

Sample Answer

**Approach (quick checklist)** When pods fail on a single node I check: node conditions, kubelet status, systemd logs, kubelet logs, container runtime health, resource pressure (disk/memory), and relevant kubectl events.

**Node & kubectl commands**- Node status and conditions:

bash

kubectl get nodes
kubectl describe node <node-name>   # shows Ready, DiskPressure, MemoryPressure, events
kubectl get pods --all-namespaces --field-selector spec.nodeName=<node-name>

**Kubelet & systemd**- Check kubelet systemd unit and journal:

bash

ssh node
sudo systemctl status kubelet
sudo journalctl -u kubelet -o cat --since "1h"

- If kubelet writes to file (distro-specific), tail the log:

bash

sudo tail -n 200 /var/log/kubelet.log

**Container runtime**- For containerd:

bash

sudo systemctl status containerd
sudo journalctl -u containerd -o cat --since "1h"
sudo ctr --namespace k8s.io containers list
sudo crictl ps -a

- For Docker:

bash

sudo systemctl status docker
sudo journalctl -u docker -o cat --since "1h"
docker ps -a

**Node resource/OS checks**- Disk, inode, memory:

bash

df -h
df -i
free -m
sudo du -sh /var/lib/kubelet /var/lib/containerd /var/lib/docker

- Kernel/OOM/dmesg:

bash

dmesg | tail -n 50
sudo journalctl -k --since "1h"

**Metrics & events**- Check kube events and pod status for errors:

bash

kubectl get events --field-selector involvedObject.nodeName=<node-name> --sort-by='.lastTimestamp'
kubectl describe pod <pod> -n <ns>
kubectl top node <node-name>   # if metrics-server installed
kubectl top pod -n <ns> --all-nodes

**What to look for / reasoning**- DiskPressure/MemoryPressure: kubelet will evict pods; check df, inodes, and kubelet eviction thresholds.- Kubelet errors in journal: auth, cgroup, eviction, or image pull issues.- Container runtime down or high error rates: pods stuck in ContainerCreating.- Kernel OOM or filesystem errors: dmesg/journalctl show root cause.

**Next steps**- Remediate (free disk/inodes, restart container runtime or kubelet), cordon/drain node:

bash

kubectl cordon <node>
kubectl drain <node> --ignore-daemonsets --delete-local-data
sudo systemctl restart containerd kubelet

Infrastructure as Code Design and ModularityEasyTechnical

21 practiced

You notice repetitive tag definitions across dozens of Terraform resources in multiple modules. Describe a DRY approach to apply a standard tagging policy across the codebase and how you'd implement it without duplicating code.

Sample Answer

**Situation & Goal**I’d centralize tag definitions so every resource uses the same canonical set without copy/paste. That keeps tags consistent and easy to update.

**DRY approach**- Create a single source of truth: a root-level locals or a dedicated module that defines standard tags.- Merge module/resource-specific tags with global tags.- Prefer provider-level defaults (e.g., aws provider.default_tags) where available to minimize per-resource config.- Enforce via module inputs and Terraform Cloud/Workspace policies if needed.

**Implementation example**- Root locals for global tags:

hcl

locals {
  standard_tags = {
    Environment = var.environment
    Team        = var.team
    Project     = var.project
  }
}

- In child modules/resources merge tags:

hcl

variable "tags" { type = map(string); default = {} }

locals {
  merged_tags = merge(local.standard_tags, var.tags)
}

resource "aws_instance" "app" {
  # ...
  tags = local.merged_tags
}

- Or set provider default tags:

hcl

provider "aws" {
  region = var.region
  default_tags { tags = local.standard_tags }
}

**Why**- Single change updates all resources.- Module inputs allow per-resource overrides without duplication.- Provider defaults reduce repetitive config and risk of omission.

**Next steps**- Add CI linting or Sentinel policy to ensure modules consume standard tags.

Continuous Integration and Delivery PipelinesMediumSystem Design

31 practiced

Design an automated promotion pipeline that moves an immutable artifact from dev -> staging -> production. Include automated gates (smoke tests, security/vulnerability scan), manual approvals, promotion triggers, artifact immutability guarantees, and a concrete rollback plan if production smoke tests fail after promotion.

Sample Answer

**Clarify goal & assumptions**- Move a single immutable artifact (container image or jar) through Dev → Staging → Production with automated gates, manual approvals, and safe rollback. Using Kubernetes, Docker registry (ECR/GCR/Artifactory), and a CI/CD tool (Jenkins/GitHub Actions/ArgoCD).

**High-level flow**1. Developer push → CI builds artifact and publishes to registry with content-addressable tag (sha256). Artifact is immutable: tag = digest (no mutable "latest").2. CI runs unit tests; on success it creates a promotion record (artifact digest + metadata) in a promotion DB (or GitOps PR).3. Promotion pipeline applies to Staging automatically; Production requires manual approval.

**Automated gates**- Dev stage: unit + static analysis.- Pre-Staging: integration + contract tests.- Staging: automated smoke tests, end-to-end tests, performance baseline, and vulnerability scan (Snyk/Trivy/Clair). All gates must pass to mark artifact promotable.

**Manual approvals & triggers**- After successful Staging gates, create a release candidate and notify stakeholders (Slack/email). Require one or two manual approvals in CI/CD (Jenkins input / GitOps PR merge) before Production.- Optionally support automated promotion for hotfix tags if policy allows.

**Deployment strategy & immutability**- Deploy by image digest to Kubernetes (Deployment with image: repo/image@sha256:...). Never reference mutable tags.- Use Blue-Green or Canary deployments: - Canary: roll out 5% → 25% → 100% with automated health checks and metrics (latency, error rate). - Blue-Green: deploy new ReplicaSet alongside current, switch service when healthy.

**Production smoke tests & rollback plan**- After router shift to new version, run automated production smoke tests against critical endpoints and health checks (synthetic transactions).- Rollback triggers: - Failing smoke tests - Error rate spike above threshold - SLO breach or significant latency regression- Rollback mechanics: - For Canary: abort rollout and revert percentage to previous digest; scale down new pods; CI/CD issues automatic rollback by re-applying previous manifest from promotion DB. - For Blue-Green: route traffic back to the green environment and decommission the new blue.- Database migrations: prefer backward-compatible migrations; if destructive migrations are required, gate them behind manual approval and include a rollback script and backup snapshot (RDS snapshot / PV backup) to restore state.

**Observability & safeguards**- Continuously monitor with Prometheus/Grafana, structured logs (ELK/CloudWatch), and alerting for rollback triggers.- Keep immutable artifact provenance in promotion DB (who, when, tests, scan results).- Periodic security re-scan and ability to revoke artifact by removing from allowed promotion list.

This design ensures artifact immutability, automated security and smoke gates, human oversight for production, and a deterministic, fast rollback path safe for production environments.

High Availability and Disaster RecoveryMediumSystem Design

72 practiced

Design a redundant load-balancer architecture for a public-facing application deployed in three availability zones. Include control-plane redundancy (config sync), health-checks, TLS termination options, session affinity, and techniques to avoid single points of failure for the load balancer itself.

Sample Answer

**Clarify requirements**- Public-facing app in 3 AZs, must be highly available, redundant control plane, health checks, TLS termination, session affinity, no LB SPOF. Cloud-agnostic but include AWS/GCP/K8s examples.

**Architecture (high-level)**- Deploy at least 2+ load-balancer instances per AZ (Nginx/HAProxy/Envoy or cloud LB) behind a regional/global front (AWS ALB+NLB or GCP External LB / Anycast CDN) so traffic routes to healthy AZs.- Use DNS with health-aware routing (Route53 failover or global load balancer) and low TTL.

**Control-plane redundancy & config sync**- Store LB config in Git + GitOps (ArgoCD/Flux). Run multiple controller replicas with leader-election disabled for reads; controllers reconcile desired state to all LB instances.- For cloud-managed LBs, use Infrastructure-as-Code (Terraform) with CI pipelines; run pipelines in multiple CI runners and store state in HA backend (S3 with DynamoDB locking).

**Health checks & failover**- Active L4 (TCP) and L7 (HTTP/HTTPS) health checks to app instances and to LB frontends (self-checks).- Use layered checks: edge LB -> regional LB -> instance. If AZ unhealthy, remove endpoints and drain connections.

**TLS termination options**- Edge termination (recommended): terminate TLS at global LB/CDN (ACM/managed certificates or ACME) to offload CPU and centralize certs.- Re-encrypt to backend: TLS between LB and app using mTLS or backend certs for end-to-end security.- Inline termination on instance if backend requires access to client cert info; use TLS passthrough (SNI) on regional LBs.

**Session affinity**- Prefer stateless sessions (JWT, cookies signed) or store sessions in central store (Redis, DynamoDB).- If sticky needed at LB: use cookie-based affinity (signed, short TTL) or consistent-hash on source IP for TCP; ensure affinity is per-AZ-aware and allow session draining during failover.

**Avoiding LB single points of failure**- Multi-AZ + multi-instance per AZ, use anycast/global IP or DNS failover.- Automate instance replacement and config rollout via GitOps/CI with canary deployments.- Use connection draining, graceful shutdown, and readiness probes to avoid dropping sessions.- Monitor with synthetic probes + alerting; automated failover runbooks.

**Operational practices**- Automate cert renewal (ACME/managed) and config rollbacks.- Test failover with chaos experiments (AZ shutdown, controller failure).- Maintain metrics: latency, 5xx rate, health-check success, stickiness ratio.

This design balances availability, security, and operational simplicity for a production public-facing app across three AZs.

Cross Functional Collaboration and CoordinationMediumTechnical

48 practiced

Dev teams prioritize feature velocity while platform teams prioritize uptime and standardization. Propose a set of incentive structures, shared KPIs, and operational agreements that align both sides to reduce toil and improve overall outcomes.

Kubernetes and Container Orchestration FundamentalsMediumSystem Design

100 practiced

Design a simple CI/CD workflow that builds a container image, runs tests, pushes to a registry, and deploys to Kubernetes. Compare an imperative pipeline that calls kubectl apply versus a GitOps approach that updates a Git repo and lets a controller (e.g., ArgoCD/Flux) reconcile the cluster.

Kubernetes TroubleshootingEasyTechnical

85 practiced

You observe a Deployment with multiple pods stuck in CrashLoopBackOff. Describe the immediate investigative steps you would take to identify the root cause and the specific commands you would run to capture evidence before taking remediation actions to restore service.

Sample Answer

**Approach (brief):**I would quickly gather observable state and logs to triage root cause, capture all evidence to immutable files, then only after evidence collection start remediation. Prioritize what affects availability (readiness/liveness, resource starvation, image/runtime errors).

Steps & commands to run (capture outputs to files):

1. Observe pods and recent events

bash

kubectl get pods -n myns -o wide > /tmp/pods.txt
kubectl get events -n myns --sort-by=.lastTimestamp > /tmp/events.txt

2. Describe a failing pod to see restart reasons, events, mounts, env, probes

bash

kubectl describe pod mypod-xxxx -n myns > /tmp/describe-mypod.txt

3. Fetch container logs (previous and current)

bash

kubectl logs mypod-xxxx -c app -n myns > /tmp/logs-mypod-current.txt
kubectl logs mypod-xxxx -c app -n myns --previous > /tmp/logs-mypod-previous.txt

4. If init containers or crashes before logging, dump pod YAML, env, and filesystem

bash

kubectl get pod mypod-xxxx -n myns -o yaml > /tmp/pod-mypod.yaml
kubectl exec -it mypod-xxxx -c app -n myns -- env > /tmp/env-mypod.txt
kubectl exec -it mypod-xxxx -c app -n myns -- ls -la /app > /tmp/ls-mypod.txt

5. Check node and resource issues

bash

kubectl get nodes -o wide > /tmp/nodes.txt
kubectl top pod -n myns > /tmp/top-pods.txt
kubectl top node > /tmp/top-nodes.txt

6. Inspect image and startup command if crash on exec

bash

kubectl get deployment mydeploy -n myns -o yaml > /tmp/deploy.yaml
kubectl rollout history deployment/mydeploy -n myns > /tmp/rollout.txt

7. Capture cluster-level logs/CRI if pod can't exec (node journal)

bash

ssh node-of-pod 'sudo journalctl -u kubelet --no-pager > /tmp/kubelet.log'

Why these steps:- describe/events show probe failures, OOMKills, CrashLoopBackOff reasons.- logs (--previous) capture the crash output.- pod YAML and env reveal misconfig, wrong args, secrets or mount issues.- node checks find resource pressure or disk issues.- Saving outputs preserves evidence for postmortem and safe rollback.

After evidence collection I'd coordinate with devs for fixes (config, image), consider scaling down/rollback, and if urgent, restart/replace pods or rollback deployment.

Infrastructure as Code Design and ModularityMediumTechnical

28 practiced

Explain how to manage provider aliases and multiple provider configurations within modules when a consumer needs resources in multiple regions or accounts. Provide examples of how to expose provider selection cleanly without coupling to consumer internals.

Sample Answer

**Brief approach**Keep provider configuration at the root (consumer) and make modules provider-agnostic. Allow the consumer to inject provider choices via the module "providers" map or a providers-per-resource map variable. Avoid hardcoding region/account in modules.

**Pattern 1 — Pass aliased provider to module**- Root defines providers with aliases per region/account- Module references provider "aws" (default) but consumer wires which alias to use

Example:

hcl

# root
provider "aws" { region = "us-east-1" }
provider "aws" { alias = "eu"; region = "eu-west-1" }

module "vpc_eu" {
  source = "./modules/vpc"
  providers = {
    aws = aws.eu
  }
}

Module: no provider config inside, just regular aws resources.

**Pattern 2 — Multi-target modules using provider map**- Module accepts a map variable of provider aliases or region keys and iterates- Consumer passes a map of configured provider aliases

hcl

# root
provider "aws" { alias = "prod-us"; region = "us-east-1" }
provider "aws" { alias = "prod-eu"; region = "eu-west-1" }

module "service" {
  source = "./modules/service-multi"
  provider_map = {
    "us" = aws.prod-us
    "eu" = aws.prod-eu
  }
}

Module uses for_each and provider meta-argument:

hcl

resource "aws_s3_bucket" "b" {
  for_each = var.provider_map
  provider = each.value
  bucket   = "svc-${each.key}"
}

**Best practices & rationale**- Configure providers only at root: simplifies credential/assume-role management.- Modules should accept provider references or logical keys — keeps them reusable.- Use named aliases and pass them via module.providers map to avoid coupling consumers to internals.- Validate with input variables and document required alias names.- For complex multi-account assume-role flows, configure provider with assume_role at root and pass those aliased providers down.

This exposes provider selection cleanly while keeping module internals independent of environment-specific config.

Continuous Integration and Delivery PipelinesEasyTechnical

40 practiced

Describe the different types of automated tests (unit, integration, contract, smoke, end-to-end) and recommend where each should run in the pipeline (PR, merge, nightly). For each type, explain trade-offs around runtime, flakiness, and confidence.

Sample Answer

**Overview (role context)** As a DevOps engineer, I design pipelines to balance fast feedback, reliability, and cost. Below I describe each test type, where to run (PR, merge/main, nightly) and trade-offs: runtime, flakiness, and confidence.

**Unit tests** - What: Fast, isolated tests of functions/modules. - Where: Run in PR and on every commit. - Trade-offs: Runtime — very fast; Flakiness — low if well-mocked; Confidence — catches logic bugs but not integration issues.

**Integration tests** - What: Tests interactions between components (DB, services). - Where: Run on merge / main (post-PR) and optionally a subset in PR for critical paths. - Trade-offs: Runtime — moderate; Flakiness — medium (depends on external dependencies); Confidence — higher for real interactions; requires stable test fixtures or containers.

**Contract tests** - What: Verify API/schema agreements between services. - Where: Run in PR for consumer-driven contracts and on merge for provider verification. - Trade-offs: Runtime — low to moderate; Flakiness — low if deterministic; Confidence — prevents breaking API changes without full E2E.

**Smoke tests** - What: Quick sanity checks of deployments (service up, basic API). - Where: Run automatically after deployments to staging and production (post-merge), and for PR deploy previews. - Trade-offs: Runtime — very fast; Flakiness — low; Confidence — low surface-level but good for deployment validation.

**End-to-end (E2E) tests** - What: Full-system tests simulating user flows (UI/API). - Where: Run nightly or on scheduled release branches; run a minimal critical-path suite on merge if needed. - Trade-offs: Runtime — long; Flakiness — high (network, timing, environment); Confidence — highest for user-facing behavior but expensive to maintain.

**Practical pipeline recipe** - PR: Unit + fast contract + critical smoke; optionally a small integration subset. - Merge/main: Full unit + integration + contract + post-deploy smoke. - Nightly / Release: Full E2E, broader integration matrix, load tests.

**Operational notes** - Use containerized test fixtures, service virtualization, and parallelization to reduce runtime and flakiness. - Track flaky tests and quarantine; invest in observability and rerun policies rather than blindly trusting failing E2Es.

Practice DevOps Engineer questions across all topics

Want to create your own tailored preparation guide using our deep research?

Get Started for Free

Interview-Ready Courses

Visual-first, interactive, structured learning paths

Browse DevOps Engineer jobs

AI-enriched listings across hundreds of company career pages

Explore Jobs

Senior DevOps Engineer Interview Preparation Guide for Microsoft

Interview Process Overview

Interview Rounds

Recruiter Screening

What to Expect

Tips & Advice

Focus Topics

Work Style and Collaboration

Practice Interview

Study Questions

Technical Experience Summary

Practice Interview

Study Questions

Career Background and Motivation

Practice Interview

Study Questions

Technical Phone Screen (Round 1)

What to Expect

Tips & Advice

Focus Topics

Cloud Platform Architecture (Azure, AWS, or GCP)

Practice Interview

Study Questions

Troubleshooting Infrastructure and Application Issues

Practice Interview

Study Questions

Container Orchestration (Kubernetes) Fundamentals

Practice Interview

Study Questions

Infrastructure as Code (Terraform, CloudFormation, ARM Templates)

Practice Interview

Study Questions

CI/CD Pipeline Design and Implementation

Practice Interview

Study Questions

Technical Phone Screen (Round 2)

What to Expect

Tips & Advice

Focus Topics

Scripting and Automation (Python, Bash, Go)

Practice Interview

Study Questions

Incident Response and Blameless Postmortems

Practice Interview

Study Questions

Secrets Management and Security Best Practices

Practice Interview

Study Questions

Infrastructure Reliability and Disaster Recovery

Practice Interview

Study Questions

Monitoring, Observability, and Alerting Strategy

Practice Interview

Study Questions

Onsite Interview - Infrastructure System Design

What to Expect

Tips & Advice

Focus Topics

Capacity Planning and Performance Optimization

Practice Interview

Study Questions

Networking, Security, and Compliance in Infrastructure Design

Practice Interview

Study Questions

Cloud Service Selection and Cost Optimization

Practice Interview

Study Questions

Distributed System Architecture and Design Patterns

Practice Interview

Study Questions

Multi-Region and High-Availability Architecture

Practice Interview

Study Questions

Onsite Interview - Kubernetes Deep Dive and Container Orchestration

What to Expect

Tips & Advice

Focus Topics

Kubernetes Storage and Stateful Workloads

Practice Interview

Study Questions