DevOps, SRE & Platform EngineeringTutorial

The Complete Interview Prep Guide: Linux, Kubernetes, AWS, Python, MCP and AI System Design

DevOps interview preparation for 2026: a 7-week roadmap, model answers for Linux, Kubernetes, AWS, Python and MCP, and two full system design walkthroughs.

Jithendar Dharmapuri

7 Nov 2026, 19:00 IST 33 min read

On this page

Five years ago a DevOps loop was Linux, a cloud, some scripting and a whiteboard. Today the same loop asks you to debug a CrashLoopBackOff, defend an IAM policy, write a retry decorator, and then design an AI agent that triages alerts without deleting production. Teams ship LLM features and wire agents into their platforms through the Model Context Protocol, and they want the people who run that platform to understand both. This guide is my DevOps interview preparation plan for that bar: what interviewers actually probe, the answers I'd give out loud, and labs you can run on a laptop.

How to use this DevOps interview preparation guide

Every topic section has the same shape: what interviewers are really testing, a concepts checklist, the most-asked questions with short model answers, one troubleshooting scenario, and a lab. Read the answers out loud. If you can't say one in under a minute without notes, you don't own it yet.

Don't memorise them: the follow-up is where seniority shows, so hang your own production stories on each one.

A 7-week roadmap

About 8–10 hours a week, assuming you already do this job. Compress it to four weeks if the interview is next month.

Week	Focus	Outcome
1	Linux internals and debugging	You debug a slow server in a fixed order and can explain load average, OOM and inodes
2	Kubernetes core and debugging	You can trace `kubectl apply` to a running pod and fix the four common failure states
3	Kubernetes operations, AWS foundations	You can talk through upgrades, backups and RBAC, and draw a three-AZ VPC from memory
4	AWS compute, data and cost	You can choose between EC2, ECS, EKS and Lambda and defend it on cost and operations
5	Python for automation	You can write the three coding problems below in 20 minutes each, with tests
6	MCP and AI system design	You can draw a RAG pipeline, say how you'd evaluate it, and build a small MCP server
7	Mocks: system design and behavioural	Two timed design mocks, five written STAR stories, one full mock loop

Linux

What interviewers are really testing: whether you have a method when a box misbehaves. They want to hear you rule things out in order rather than reboot, and to know you understand what the numbers mean.

Linux concepts checklist

Boot: firmware (UEFI or BIOS), GRUB 2, kernel and initramfs, PID 1 (systemd), targets
Processes: fork/exec, states (R, S, D, Z, T), signals, zombies and orphans
systemd: units, targets, restart policy, journald, cgroups
Permissions: mode bits, setuid/setgid/sticky, umask, ACLs, capabilities
Filesystems: inodes, hard and soft links, deleted-but-open files
Memory and CPU: page cache, swap, OOM killer, load average, iowait, steal, Pressure Stall Information (PSI)
Networking: ip, ss, tcpdump, the DNS resolution path, TCP states

Scenario: "The server is slow"

The trap is jumping to a fix. Say your order out loud first.

Define slow. Which requests, since when, for whom? What changed: deploy, traffic, a cron job?
One-line picture. Load versus CPU count, and PSI, which tells you directly how much time tasks stalled on CPU, memory or I/O:

Bash

uptime                 # load averages vs. CPU count (nproc)
cat /proc/pressure/cpu /proc/pressure/memory /proc/pressure/io

CPU, memory and run queue over a few seconds.

Bash

vmstat 1 5             # r = run queue, si/so = swapping, wa = iowait, st = steal
free -h

Disk.

Bash

iostat -xz 1 3         # %util and await per device (sysstat package)
df -h && df -i

Which process?

Bash

pidstat -u -d 1 5                                     # per-process CPU and disk
ps -eo pid,stat,wchan:20,cmd | awk '$2 ~ /^D/'        # tasks stuck in D state
journalctl -k --since "1 hour ago" | grep -i -E 'oom|killed process'

Network.

Bash

ss -s
ss -tanp state close-wait | head
ip -br addr && ip route get 1.1.1.1

Go deeper on the suspect with strace -f -tt -p <pid> to see which syscall it's blocked on, or perf top to see where CPU goes.

Finish with the fix and the alert you'd add so you hear about it first next time.

Lab: break a box on purpose

Use a throwaway VM (Multipass, UTM or a free-tier EC2 instance) with stress-ng and sysstat installed:

Bash

# CPU pressure: watch load average and /proc/pressure/cpu climb
stress-ng --cpu "$(nproc)" --timeout 60s

# OOM inside a cgroup: systemd kills it when it passes 200 MB
sudo systemd-run --scope -p MemoryMax=200M stress-ng --vm 1 --vm-bytes 400M --timeout 30s
journalctl -k --since "5 min ago" | grep -i oom

# Deleted-but-open file
python3 -c "import time; f=open('/tmp/big','w'); f.write('x'*200_000_000); f.flush(); time.sleep(600)" &
sleep 5 && rm /tmp/big && df -h /tmp && sudo lsof +L1 | grep /tmp/big

Each time, run the slow-server checklist and note which command found the problem first.

Kubernetes

What interviewers are really testing: whether you understand the control loop well enough to predict what Kubernetes will do, and whether you debug from events and status rather than guessing.

Kubernetes concepts checklist

Control plane (API server, etcd, scheduler, controller manager) and node (kubelet, runtime, kube-proxy or an eBPF replacement)
Pod lifecycle: phases, container states, init and sidecar containers, termination
Scheduling: requests vs. limits, QoS classes, taints and tolerations, affinity, topology spread
Probes: startup, readiness, liveness
Networking: Services, EndpointSlices, DNS, Ingress, Gateway API, NetworkPolicy
Security: RBAC, ServiceAccounts, Pod Security Admission
Scaling and state: HPA, Cluster Autoscaler or Karpenter, StatefulSets, PVCs
Operations: etcd snapshots, Velero, upgrades and version skew

Scenario: a rollout is stuck and pods are crash-looping

Scope it. One deployment or the whole namespace? Did a rollout just happen?

Bash

kubectl rollout status deployment/web -n shop
kubectl get pods -n shop -l app=web -o wide
kubectl get events -n shop --sort-by=.lastTimestamp | tail -20

Read why the last container died.

Bash

kubectl describe pod <pod> -n shop        # Last State, Reason, Exit Code, probe failures
kubectl logs <pod> -n shop --previous

Branch on the evidence. OOMKilled: raise the limit or fix the leak. Liveness failures in events: the probe is too aggressive for startup, so add a startup probe. An app error: diff config and secrets against the previous ReplicaSet.

Bash

kubectl rollout history deployment/web -n shop
kubectl diff -f deploy/web.yaml

Restore service first, debug second.

Bash

kubectl rollout undo deployment/web -n shop

With GitOps, revert the commit instead, or Argo CD or Flux will put the broken version straight back.

If logs aren't enough, attach a debug container to the pod:

Bash

kubectl debug -it <pod> -n shop --image=busybox:1.36 --target=web

A probe and resource setup that prevents most of these incidents:

YAML

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
  namespace: shop
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      terminationGracePeriodSeconds: 30
      containers:
        - name: web
          image: nginx:1.27
          ports:
            - containerPort: 80
          resources:
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              memory: 128Mi
          startupProbe:
            httpGet:
              path: /
              port: 80
            failureThreshold: 30
            periodSeconds: 2
          readinessProbe:
            httpGet:
              path: /
              port: 80
            periodSeconds: 5
          livenessProbe:
            httpGet:
              path: /
              port: 80
            periodSeconds: 10
            failureThreshold: 3

Lab: a failure zoo on Minikube

Bash

minikube start --nodes 3 --cpus 2 --memory 4g
minikube addons enable metrics-server
kubectl create namespace zoo

# CrashLoopBackOff
kubectl -n zoo create deployment crash --image=busybox:1.36 -- sh -c 'echo starting; exit 1'
# ImagePullBackOff
kubectl -n zoo run badimage --image=nginx:does-not-exist
# Pending: asks for more CPU than any node has
kubectl -n zoo create deployment hungry --image=nginx:1.27
kubectl -n zoo set resources deployment hungry --requests=cpu=64

kubectl -n zoo get pods -w

Diagnose each using only describe, logs and events. Then create the shop namespace, apply the Deployment above, and add an HPA:

YAML

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web
  namespace: shop
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web
  minReplicas: 3
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 60

Stretch goal: install Velero against a local MinIO bucket, run velero backup create shop-test --include-namespaces shop, delete the namespace, and bring it back with velero restore create --from-backup shop-test.

AWS

What interviewers are really testing: whether you design for failure and cost at the same time, and understand IAM well enough to explain why a request was denied.

AWS concepts checklist

VPC: CIDR planning, subnets per AZ, route tables, NAT gateways, VPC endpoints, security groups vs. NACLs
IAM: identity vs. resource policies, roles and STS, permission boundaries, SCPs, evaluation order, Access Analyzer
Compute: EC2 and Auto Scaling, ECS (EC2 and Fargate), EKS, Lambda
Data: S3 classes and lifecycle, EBS vs. EFS, RDS and Aurora, DynamoDB
Load balancing: ALB vs. NLB, target groups, health checks
Observability: CloudWatch metrics, logs, alarms, Logs Insights, CloudTrail
Resilience and cost: multi-AZ vs. multi-region, RTO/RPO, Savings Plans, Spot, Graviton, data transfer

Scenario: an app in a private subnet can't reach S3

Is it AccessDenied or a timeout? They have completely different causes.

Bash

aws sts get-caller-identity
aws s3 ls s3://my-app-bucket/ --debug 2>&1 | tail -20

A timeout is the network. Does the subnet's route table have a NAT route or an S3 gateway endpoint? If there's an endpoint, does its policy allow this bucket? Do the security group and NACL allow outbound HTTPS?
AccessDenied is policy. Simulate the role's identity policy:

Bash

aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::123456789012:role/app-role \
  --action-names s3:GetObject \
  --resource-arns arn:aws:s3:::my-app-bucket/config.json

Then the other side: the bucket policy (an explicit deny, or an aws:SourceVpce condition that doesn't match), an SCP, and, for objects encrypted with a customer-managed KMS key, whether the role can call kms:Decrypt. The KMS one catches people constantly.
Confirm in CloudTrail, which records the denied call, the principal, and often which policy type denied it.

The least-privilege policy for this workload:

JSON

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ReadAppConfig",
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::my-app-bucket/config/*"
    },
    {
      "Sid": "ListConfigPrefix",
      "Effect": "Allow",
      "Action": ["s3:ListBucket"],
      "Resource": "arn:aws:s3:::my-app-bucket",
      "Condition": { "StringLike": { "s3:prefix": ["config/*"] } }
    }
  ]
}

Lab: a small, cheap, real environment

Set an AWS Budget alarm first. Then use Terraform to build a VPC with public and private subnets in two AZs and an EC2 instance in the private subnet with no public IP, and reach it through SSM Session Manager instead of SSH. Add an S3 gateway endpoint, remove the NAT route, and prove the instance can reach S3 but not the internet. Run terraform destroy the same day. My Terraform tutorial walks through a real repository.

Python

What interviewers are really testing: whether you write automation someone else can run at 3 a.m.: timeouts, real error handling, exit codes and tests. Algorithms matter less than in a software engineering loop.

Python concepts checklist

Data structures: list, dict, set, collections (Counter, defaultdict, deque) and their complexity
Generators, comprehensions, itertools
Decorators, closures, functools.wraps
Context managers and contextlib
Concurrency: threads, processes, asyncio, the GIL
Errors: specific except, re-raising, finally, exit codes
Automation: argparse, subprocess, logging, HTTP clients with timeouts
Testing: pytest fixtures, parametrize, monkeypatch, tmp_path

Coding problem 1: parse an access log

Given an Nginx access log with request time as the last field, report the status code mix, the top paths returning 5xx, and p95 latency per path.

Python

"""Summarise an Nginx access log: status mix, top 5xx paths, p95 latency per path."""
import math
import re
import sys
from collections import Counter, defaultdict

# Combined log format with $request_time appended as the last field.
LINE = re.compile(
    r'(?P<ip>\S+) \S+ \S+ \[(?P<ts>[^\]]+)\] '
    r'"(?P<method>[A-Z]+) (?P<path>[^ ?"]+)[^"]*" '
    r'(?P<status>\d{3}) (?P<size>\d+|-) "[^"]*" "[^"]*" (?P<rt>\d+(?:\.\d+)?)$'
)


def parse(lines):
    """Yield one dict per valid line. A generator, so a 20 GB log never sits in memory."""
    for line in lines:
        match = LINE.match(line.rstrip("\n"))
        if match:
            yield match.groupdict()


def p95(values):
    ordered = sorted(values)
    return ordered[math.ceil(0.95 * len(ordered)) - 1]  # nearest-rank


def summarise(lines):
    statuses, errors, latency = Counter(), Counter(), defaultdict(list)
    for rec in parse(lines):
        statuses[rec["status"]] += 1
        if rec["status"].startswith("5"):
            errors[rec["path"]] += 1
        latency[rec["path"]].append(float(rec["rt"]))
    return {
        "statuses": dict(statuses),
        "top_5xx": errors.most_common(5),
        "p95": {path: p95(v) for path, v in latency.items()},
    }


if __name__ == "__main__":
    with open(sys.argv[1], encoding="utf-8", errors="replace") as fh:
        report = summarise(fh)
    print("status codes:", report["statuses"])
    print("top 5xx paths:", report["top_5xx"])
    for path, value in sorted(report["p95"].items(), key=lambda kv: -kv[1])[:5]:
        print(f"p95 {value:.3f}s  {path}")

Talk through the choices: the generator keeps memory flat, query strings are stripped so paths group together, and malformed lines and bad bytes don't crash the run.

Coding problem 2: retry with exponential backoff

Python

"""Retry a flaky call with capped exponential backoff and full jitter."""
import functools
import random
import time


def retry(attempts=5, base=0.2, cap=5.0, retry_on=(ConnectionError, TimeoutError), sleep=time.sleep):
    def decorator(func):
        @functools.wraps(func)
        def wrapper(*args, **kwargs):
            for attempt in range(1, attempts + 1):
                try:
                    return func(*args, **kwargs)
                except retry_on:
                    if attempt == attempts:
                        raise  # out of budget: surface the real error
                    # Full jitter: random wait in [0, min(cap, base * 2^n)].
                    sleep(random.uniform(0, min(cap, base * 2 ** (attempt - 1))))
        return wrapper
    return decorator

And the tests:

Python

import pytest

from retry import retry


def test_succeeds_after_transient_failures():
    calls = []

    @retry(attempts=3, sleep=lambda _: None)
    def flaky():
        calls.append(1)
        if len(calls) < 3:
            raise ConnectionError("reset by peer")
        return "ok"

    assert flaky() == "ok"
    assert len(calls) == 3


def test_gives_up_and_reraises():
    @retry(attempts=2, sleep=lambda _: None)
    def always_down():
        raise TimeoutError("upstream timeout")

    with pytest.raises(TimeoutError):
        always_down()


def test_does_not_retry_bugs():
    calls = []

    @retry(attempts=5, sleep=lambda _: None)
    def buggy():
        calls.append(1)
        raise ValueError("bad input")

    with pytest.raises(ValueError):
        buggy()
    assert len(calls) == 1

What interviewers listen for: jitter, so a thousand clients don't retry in lockstep after an outage; caps on delay and attempts; retrying only transient errors; and an injectable sleep so tests run instantly. Retries also need idempotent operations.

Coding problem 3: parallel health checks

Python

"""Check many HTTP endpoints in parallel with a per-request timeout."""
import sys
import time
import urllib.error
import urllib.request
from concurrent.futures import ThreadPoolExecutor, as_completed


def check(url, timeout=3.0):
    start = time.monotonic()
    try:
        with urllib.request.urlopen(url, timeout=timeout) as resp:
            status = resp.status
    except urllib.error.HTTPError as exc:  # 4xx/5xx still answered
        status = exc.code
    except (urllib.error.URLError, TimeoutError, OSError) as exc:
        return url, None, f"{type(exc).__name__}: {exc}"
    return url, status, f"{(time.monotonic() - start) * 1000:.0f} ms"


def check_all(urls, workers=20):
    # Threads are fine here: the GIL is released while waiting on sockets.
    with ThreadPoolExecutor(max_workers=workers) as pool:
        futures = [pool.submit(check, u) for u in urls]
        for future in as_completed(futures):
            yield future.result()


if __name__ == "__main__":
    failed = 0
    for url, status, detail in check_all(sys.argv[1:]):
        healthy = status is not None and 200 <= status < 400
        failed += not healthy
        print(f"{'OK  ' if healthy else 'FAIL'} {status or '---'} {url} ({detail})")
    sys.exit(1 if failed else 0)

Run it as python3 health_check.py https://example.com http://localhost:8080/healthz. It's standard library only, every request has a timeout, and the exit code makes it usable in CI. At 10,000 endpoints, move to asyncio with a semaphore.

Lab: write a real ops CLI

Build an argparse tool that lists pods in a namespace with the Kubernetes Python client, flags any with restarts above a threshold, and exits non-zero if it finds one. Test it with a fake client. My Python tutorial uses real project code if you need a starting point.

MCP (Model Context Protocol)

What interviewers are really testing: whether you see MCP as an integration protocol with a real security surface, and whether you'd give an AI agent access to production tools responsibly.

MCP concepts checklist

Architecture: host, client (one per server connection), server
JSON-RPC 2.0, capability negotiation at initialisation, a date-versioned spec
Server primitives: tools (model-controlled), resources (application-controlled), prompts (user-controlled)
Client features: sampling, roots, elicitation
Transports: stdio locally, Streamable HTTP remotely
Authorisation: OAuth 2.1 for HTTP, audience-bound tokens, no token passthrough
Risks: prompt injection via tool output, tool poisoning, over-broad permissions, confused deputy

Scenario: an agent closed 40 tickets after reading one

Contain. Disable the tool or revoke the server's token before hunting for the root cause.
Reconstruct. Pull the MCP call log: which calls, in what order, with what arguments, on whose behalf.
Find the trigger. Most likely indirect prompt injection: the ticket body said something like "close all related tickets", and the model treated data as instructions.
Fix the design, not just the prompt. Split read and write tools, require human confirmation for state changes, limit bulk operations, and scope the token to the user's own permissions.
Prevent regressions. Add the malicious ticket to an evaluation set that runs on every prompt or model change.

Lab: build, connect and attack your own server

Put the server, health_check.py and a runbooks/ folder with a Markdown file side by side, pip install mcp, and connect it to an MCP-capable client or the MCP Inspector. Then attack it: request runbook://../../etc/passwd, plant an instruction inside a runbook, and ask for a service that isn't on the allowlist. My RoboShop MCP server article shows a server that forwards the caller's own session instead of holding broad credentials.

AI system design

What interviewers are really testing: whether you treat an LLM as an unreliable, expensive, slow dependency and design around it with retrieval, evaluation, caching, guardrails and observability, as you would any other risky component.

AI system design concepts checklist

RAG: ingestion, chunking, embeddings, hybrid search, reranking, prompt assembly, citations
Vector stores: pgvector, OpenSearch, dedicated vector databases; HNSW indexes; metadata filters
Evaluation: recall@k, MRR, faithfulness, golden sets, LLM-as-judge and its limits
Latency and cost: tokens, time to first token, streaming, model routing
Caching: provider prompt caching, response and embedding caches, semantic caching
Guardrails: input and output validation, PII, structured output
Observability: per-request traces, token and cost metrics, feedback
Agents: tool use, step limits, human-in-the-loop, audit

Scenario: the RAG assistant started giving wrong answers last week

Define wrong: wrong facts, outdated answers, or "I don't know" when the answer exists?
Check what changed: model, prompt, embedding model, chunking or a re-index. Changing the embedding model without re-embedding everything silently breaks retrieval.
Split retrieval from generation. In each bad trace, were the right chunks retrieved? If not, fix retrieval; if they were, look at the prompt or model.
Check freshness. A stalled ingestion job is the most common cause of "it used to know this".
Reproduce in the evaluation set, fix it, and keep the cases so the regression can't return silently.

Lab: a local RAG with an evaluation harness

Run Postgres with pgvector in Docker, embed your own notes or runbooks with a local embedding model, and build a small retrieval API. Write 30 questions with known answers and measure recall@5 before and after changing chunk size. I wrote up adding PyTorch reranking to my SRE assistant's RAG pipeline.

System design walkthrough 1: an AI SRE agent that triages Kubernetes alerts

Spend the first five of 45 minutes on requirements; most candidates skip them.

Requirements: SRE agent

Functional: receive Alertmanager alerts; gather context (pod status, events, logs, metrics, recent deploys); find runbooks and past incidents; post a summary with likely cause and suggested fix to on-call; execute an action only after a human approves it.
Non-functional: first summary within 60 seconds; no change without approval; every action audited; 20 clusters; if the AI path fails, the alert still reaches on-call unchanged; cost per triage tracked.
Out of scope for v1: autonomous remediation and alert rule tuning.

High-level design: SRE agent

Mermaid

flowchart LR
  AM[Alertmanager] -->|webhook| IN[Ingest and dedup]
  IN --> Q[(Queue)]
  Q --> TR[Triage worker]
  TR --> CTX[Context gatherers<br/>read-only]
  CTX --> K8S[Kubernetes API]
  CTX --> PROM[Prometheus]
  CTX --> LOGS[Loki]
  CTX --> GIT[Argo CD / Git history]
  TR --> RAG[RAG over runbooks<br/>and postmortems]
  TR --> LLM[LLM gateway]
  TR --> OUT[Slack / incident tool]
  OUT -->|approve| POL[Policy check]
  POL --> EX[Executor<br/>scoped credentials]
  EX --> K8S
  TR --> AUD[(Audit log and traces)]
  EX --> AUD

Deep dive: SRE agent

Ingestion. Alertmanager already groups alerts; I deduplicate by fingerprint and queue the work, so a storm of 500 alerts becomes a handful of triage jobs and the webhook never blocks.

Context gathering is code, not the model. For KubePodCrashLooping, the worker always fetches the pod description, previous container logs, recent events, rollout history and the matching Argo CD sync. The model gets curated context, not a shell.

Retrieval. Runbooks and postmortems are indexed with alert name, service and cluster as metadata. Filtering on the alert name before semantic search puts the right runbook first almost every time.

Reasoning. The model returns structured output: probable cause, evidence with links, confidence, and actions picked from a fixed catalogue such as roll back, scale up or restart. It can't invent commands.

Human-in-the-loop. Suggestions arrive in Slack with approve and reject buttons. On approval, a policy engine checks the action (no deletes, no production changes during a freeze, a blast-radius limit), and an executor with a narrowly scoped ServiceAccount per cluster runs it. In MOKS, the SRE portal I run on my own cluster, read-only diagnostics run without approval but restores wait for a human, and that split is the most important decision in the design.

Trade-offs: SRE agent

Fixed workflows vs. an agent loop. Per-alert workflows are predictable and cheap; an agent handles the long tail. Start with workflows for the top ten alerts and a constrained agent for the rest.
Self-hosted vs. API models. Logs can hold secrets and customer data, so data handling may decide this before quality does. Redact secrets before anything leaves the cluster either way.

Scaling and failure modes: SRE agent

LLM slow or down: time out at 30 seconds and post the alert with the gathered context, which is useful on its own.
Alert storm: dedup, queue and a per-cluster concurrency limit; triage the first alert in a correlated group.
Prompt injection through logs: logs are untrusted, and the action catalogue plus policy engine mean even a manipulated model can only suggest something a human must approve.
Wrong suggestions erode trust: show evidence and confidence, track acceptance per alert type, and switch suggestions off where it's low.
Executor credentials: per cluster and per action, short-lived, every use logged.

For more depth, my MOKS RAG and skills design covers retrieval and governance, and LangChain vs. LangGraph for an SRE agent covers orchestration.

System design walkthrough 2: a highly available multi-region web platform on AWS and EKS

Requirements: multi-region platform

Functional: a customer-facing web app and API with accounts, orders and a product catalogue.
Non-functional: 99.95% availability; survive an AZ loss with no manual action and a region loss within 15 minutes (RTO) with under a minute of data loss (RPO); p99 API latency under 300 ms on two continents; zero-downtime deploys several times a day.
Clarify: read/write ratio, data residency, and whether writes must be accepted in both regions. That last answer drives most of the design.

High-level design: multi-region platform

Mermaid

flowchart TB
  U[Users] --> R53[Route 53<br/>latency + health checks]
  R53 --> CF[CloudFront + WAF]
  CF --> ALB1[ALB region A]
  CF --> ALB2[ALB region B]
  subgraph A[Region A primary]
    ALB1 --> EKS1[EKS across 3 AZs<br/>Karpenter nodes]
    EKS1 --> AUR1[(Aurora writer)]
    EKS1 --> DDB1[(DynamoDB global table)]
    EKS1 --> RED1[(ElastiCache)]
  end
  subgraph B[Region B standby]
    ALB2 --> EKS2[EKS across 3 AZs<br/>Karpenter nodes]
    EKS2 --> AUR2[(Aurora secondary<br/>read-only)]
    EKS2 --> DDB2[(DynamoDB global table)]
    EKS2 --> RED2[(ElastiCache)]
  end
  AUR1 -. storage replication .-> AUR2
  DDB1 <-. multi-active replication .-> DDB2
  GIT[Git + Argo CD] --> EKS1
  GIT --> EKS2
  ECR[ECR with cross-region replication] --> EKS1
  ECR --> EKS2

Deep dive: multi-region platform

Edge. CloudFront serves static assets and terminates TLS near users, with WAF in front; Route 53 latency-based routing with health checks sends API traffic to the nearest healthy region.

Per region. A three-AZ VPC, an ALB, and EKS with Karpenter provisioning nodes across AZs. Topology spread constraints put replicas in every AZ, and PodDisruptionBudgets stop node rotations from breaking quorum.

Data is the hard part, so I split it by consistency needs:

Orders and accounts in Aurora PostgreSQL with Aurora Global Database: region A writes, region B holds a read-only secondary with lag typically under a second, and we promote B if A fails.
Sessions and carts in DynamoDB global tables, which accept writes in both regions with last-writer-wins conflict resolution: fine for a cart, not for an order.
ElastiCache per region as a pure cache, so losing it costs latency, not data.
S3 for media with cross-region replication.

Deploys. ECR replicates images across regions, and Argo CD syncs the standby region first as a canary, with automated rollback on error rate.

Trade-offs: multi-region platform

Active/passive vs. active/active writes. Active/active orders need conflict-free data models or a globally consistent database and much harder testing. With a 15-minute RTO, active/passive writes and active/active reads is the honest answer.
Cost. A warm standby roughly doubles the baseline. Region B can run smaller and scale on failover, but then that scale-up, including EC2 capacity in that region, has to be tested.
EKS vs. ECS. EKS is justified if the company already runs Kubernetes; otherwise ECS on Fargate removes a lot of operational work. Say that out loud.

Scaling and failure modes: multi-region platform

Failure	What happens	Mitigation
One AZ lost	ALB stops routing there; Karpenter replaces capacity; Aurora moves the writer if needed	Three AZs, topology spread, PDBs, ~30% headroom
EKS control plane issue in a region	Running pods keep serving; no deploys or scaling	Freeze deploys there; shift traffic via Route 53 if needed
Bad deploy	Error rate rises in the canary region	Automated rollback, one region at a time
Region A lost	Health checks shift traffic to B; writes fail until promotion	Practised Aurora promotion runbook or automation
Payments provider outage	Checkout fails	Timeouts, circuit breakers, queue orders for later

The closing line I'd give: none of this is real until it's tested. Run game days that fail an AZ and then a region, and measure actual RTO and RPO against the targets.

The behavioural round

Senior engineers fail loops here more often than they admit. Interviewers want evidence of judgement and ownership.

Five questions to prepare

Tell me about the worst production incident you were part of.
Tell me about a time you disagreed with a technical decision.
Describe something you automated that saved your team real time.
Tell me about a change you made that caused an outage.
How have you improved on-call for your team?

STAR tips for incident stories

Situation: one or two sentences with scale and stakes: "checkout was failing for 30% of users at peak."
Task: your specific role: incident commander, debugger, communicator.
Action: most of your time goes here: what you checked in what order, what you ruled out, and the trade-offs, such as rolling back before knowing the root cause.
Result: numbers: time to mitigate, customer impact, and follow-ups that shipped, not just ones that were filed.
Reflection: what you'd do differently, in blameless language. "The pipeline allowed it" lands better than naming a colleague.

Have one story where you were the cause, and what you changed so nobody else can repeat it.

Common mistakes candidates make

Jumping to a fix before asking what changed and what "slow" means.
Listing tools instead of a method: "I'd use Prometheus" isn't an answer.
Designing without requirements, or ignoring cost.
Treating AI as magic: no evaluation plan, no guardrails, no fallback when the model is slow or wrong.
Giving an agent broad credentials "for now".
Saying "it depends" and stopping. Say what it depends on, then choose.
Python with no timeouts, a bare except: and no exit codes.
Bluffing. "I haven't run that at scale, but here's how I'd test it" is a strong sentence.

The day before the interview

Map each line of the job description to one story or answer.
Say the slow-server and CrashLoopBackOff walkthroughs out loud once.
Redraw both system designs from memory in under 10 minutes each.
Write the retry decorator from scratch.
Review your five STAR stories, with numbers.
Prepare three questions for them: on-call load, how incidents are reviewed, how they use AI in operations.
Test camera, microphone and screen sharing, and have a plain editor ready.
Sleep. A rested brain debugs better than a crammed one.

Conclusion

You still need deep Linux, Kubernetes and AWS fundamentals, but now you're also expected to automate cleanly in Python and reason about AI systems and the protocols that connect them to production. The same habits cover all of it: ask what changed, gather evidence before acting, design for failure, keep permissions narrow, and measure everything.

Treat this DevOps interview preparation guide as a plan, not a script. Run the labs, break things on purpose, and turn what you learn into your own stories.

If it helped, subscribe to jithendar.com for more hands-on posts. Good next reads are my MOKS RAG and skills design and the RoboShop MCP server walkthrough.

Frequently asked questions

How long does DevOps interview preparation take?

For someone already working in DevOps or SRE, six to eight weeks at 8–10 hours a week covers Linux, Kubernetes, AWS, Python and AI system design properly. With less time, prioritise the troubleshooting walkthroughs and one system design.

Do DevOps interviews now include AI and MCP questions?

Increasingly, especially at product companies and startups that ship LLM features. Expect RAG architecture, evaluating and observing LLM apps, and how you'd give an AI agent safe access to tools, which is where MCP comes in.

Which Kubernetes topics come up most in SRE interviews?

Pod lifecycle and probes, debugging CrashLoopBackOff, ImagePullBackOff and Pending, requests and limits, RBAC, autoscaling, and upgrades and backups.

How much Python do I need for a DevOps interview?

Enough to write clean automation under time pressure: parse logs, call APIs with timeouts and retries, run work in parallel, handle errors and write pytest tests. Heavy algorithm questions are rarer than in software engineering loops.

How do I practise system design for DevOps roles?

Take a prompt, set 45 minutes, and talk through requirements, high-level design, deep dive, trade-offs and failure modes, ideally with a peer.

Sources

1.Kubernetes Documentation: Pod Lifecycle — The Kubernetes Authors
2.Kubernetes Documentation: Version Skew Policy — The Kubernetes Authors
3.Kubernetes Documentation: Horizontal Pod Autoscaling — The Kubernetes Authors
4.Gateway API — Kubernetes SIG Network
5.Ingress NGINX Retirement: What You Need to Know — The Kubernetes Authors
6.Policy evaluation logic — Amazon Web Services
7.Disaster Recovery of Workloads on AWS — Amazon Web Services
8.Model Context Protocol Specification — Model Context Protocol
9.MCP Security Best Practices — Model Context Protocol
10.MCP Python SDK — Model Context Protocol
11.PEP 779: Criteria for supported status for free-threaded Python — Python Software Foundation
12.Velero Documentation — Velero project

Discussion comments

No comments yet. Start the discussion.

AI Agents, MCP & LLMOpsAnalysis
How MOKS works: RAG and SKILL.md playbooks in an AI SRE investigation portal
The design of MOKS, an AI SRE portal: permission-aware hybrid RAG, versioned SKILL.md playbooks, and why knowledge is data while skills are instructions.
31 Oct 202618 min read
AI Agents, MCP & LLMOpsTutorial
Building an MCP Server for RoboShop AI
A code-level MCP server walkthrough: roles, transports, tool schemas, session forwarding, trust boundaries and the risks that remain in RoboShop AI.
1 Nov 202613 min read
AI Agents, MCP & LLMOpsAnalysis
LangChain vs LangGraph for an SRE agent: what MOKS actually uses
How the MOKS SRE agent uses LangGraph for its investigation loop and langchain-core for thin adapters, with real code, a traced run and known gaps.
1 Nov 202624 min read

How to use this DevOps interview preparation guide

A 7-week roadmap

Linux

Linux concepts checklist

Top Linux questions and model answers

Scenario: "The server is slow"

Lab: break a box on purpose

Kubernetes

Kubernetes concepts checklist

Top Kubernetes questions and model answers

Scenario: a rollout is stuck and pods are crash-looping

Lab: a failure zoo on Minikube

AWS

AWS concepts checklist

Top AWS questions and model answers

Scenario: an app in a private subnet can't reach S3

Lab: a small, cheap, real environment

Python

Python concepts checklist

Top Python questions and model answers

Coding problem 1: parse an access log

Coding problem 2: retry with exponential backoff

Coding problem 3: parallel health checks

Lab: write a real ops CLI

MCP (Model Context Protocol)

MCP concepts checklist

Top MCP questions and model answers

Scenario: an agent closed 40 tickets after reading one

Lab: build, connect and attack your own server

AI system design

AI system design concepts checklist

Top AI system design questions and model answers

Scenario: the RAG assistant started giving wrong answers last week

Lab: a local RAG with an evaluation harness

System design walkthrough 1: an AI SRE agent that triages Kubernetes alerts

Requirements: SRE agent

High-level design: SRE agent

Deep dive: SRE agent

Trade-offs: SRE agent

Scaling and failure modes: SRE agent

System design walkthrough 2: a highly available multi-region web platform on AWS and EKS

Requirements: multi-region platform

High-level design: multi-region platform

Deep dive: multi-region platform

Trade-offs: multi-region platform

Scaling and failure modes: multi-region platform

The behavioural round

Five questions to prepare

STAR tips for incident stories

Common mistakes candidates make

The day before the interview

Conclusion

Frequently asked questions

How long does DevOps interview preparation take?

Do DevOps interviews now include AI and MCP questions?

Which Kubernetes topics come up most in SRE interviews?

How much Python do I need for a DevOps interview?

How do I practise system design for DevOps roles?

Sources

Discussion comments

Related reading

How MOKS works: RAG and SKILL.md playbooks in an AI SRE investigation portal

Building an MCP Server for RoboShop AI

LangChain vs LangGraph for an SRE agent: what MOKS actually uses