DevOps interviews assess a unique combination of development, operations, and automation culture skills. This guide compiles the most frequently asked questions, organized by domain, with structured answers that demonstrate deep mastery of the concepts. Beyond technical knowledge, recruiters evaluate the ability to explain complex concepts simply and share concrete problem-solving experiences. ## DevOps Fundamentals and Culture Initial questions often assess the overall understanding of DevOps philosophy. **Q1: What is DevOps and what problems does this approach solve?** DevOps represents a culture and set of practices that unify software development (Dev) and IT operations (Ops). This approach aims to shorten the development cycle while maintaining high quality. ```yaml # devops-principles.yaml # The pillars of DevOps culture principles: collaboration: description: "Breaking silos between teams" practices: - "Shared responsibility for production code" - "Continuous communication via ChatOps" - "Blameless post-mortems" automation: description: "Automate repetitive tasks" practices: - "Infrastructure as Code (IaC)" - "CI/CD pipelines" - "Automated testing at all levels" measurement: description: "Measure to improve" metrics: - "Deployment frequency" - "Lead time for changes" - "Mean time to recovery (MTTR)" - "Change failure rate" sharing: description: "Share knowledge" practices: - "Documentation as Code" - "Automated runbooks" - "Regular knowledge sharing sessions" ``` Problems solved include slow and risky deployments, lack of visibility between teams, and inconsistency across environments. **Q2: What is the difference between CI, CD (Continuous Delivery) and CD (Continuous Deployment)?** These three concepts form a progression in delivery cycle automation. ```bash # ci-cd-pipeline-stages.sh # Illustration of CI/CD stages # ============================================ # CI (Continuous Integration) # ============================================ # Goal: Frequently integrate code into a shared repository # Automation: Build + Tests echo "CI: Code commit → Build → Unit Tests → Integration Tests" # ============================================ # CD (Continuous Delivery) # ============================================ # Goal: Code always deployable to production # Automation: CI + Staging deployment + Manual approval echo "CD Delivery: CI → Deploy Staging → Manual Approval → Deploy Prod" # ============================================ # CD (Continuous Deployment) # ============================================ # Goal: Automatic deployment to production # Automation: Entire pipeline without human intervention echo "CD Deployment: CI → Deploy Staging → Auto Tests → Auto Deploy Prod" ``` The key distinction lies in the level of automation: Continuous Delivery requires manual validation before production, while Continuous Deployment fully automates the process. ## CI/CD and Pipelines CI/CD questions test the ability to design and optimize delivery pipelines. **Q3: How to structure a robust CI/CD pipeline?** A well-designed pipeline follows progressive stages with checkpoints at each level. ```yaml # .gitlab-ci.yml # Complete CI/CD pipeline with parallel and sequential stages stages: - validate - build - test - security - deploy-staging - integration-tests - deploy-production variables: DOCKER_IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA # ============================================ # Stage 1: Fast validation (< 2 min) # ============================================ lint: stage: validate script: - npm run lint - npm run type-check # Run on every commit rules: - if: $CI_PIPELINE_SOURCE == "merge_request_event" - if: $CI_COMMIT_BRANCH # ============================================ # Stage 2: Application build # ============================================ build: stage: build script: - docker build -t $DOCKER_IMAGE . - docker push $DOCKER_IMAGE # Cache Docker layers to speed up builds cache: key: docker-$CI_COMMIT_REF_SLUG paths: - .docker-cache/ # ============================================ # Stage 3: Parallel tests # ============================================ unit-tests: stage: test script: - npm run test:unit -- --coverage coverage: '/Lines\s*:\s*(\d+\.?\d*)%/' artifacts: reports: coverage_report: coverage_format: cobertura path: coverage/cobertura-coverage.xml integration-tests: stage: test services: - postgres:16-alpine - redis:7-alpine script: - npm run test:integration # Parallelization with unit tests parallel: 3 # ============================================ # Stage 4: Security analysis # ============================================ sast: stage: security script: - trivy image --exit-code 1 --severity HIGH,CRITICAL $DOCKER_IMAGE allow_failure: false dependency-scan: stage: security script: - npm audit --audit-level=high allow_failure: true # Alert without blocking # ============================================ # Stage 5: Staging deployment # ============================================ deploy-staging: stage: deploy-staging script: - kubectl set image deployment/app app=$DOCKER_IMAGE -n staging - kubectl rollout status deployment/app -n staging --timeout=300s environment: name: staging url: https://staging.example.com only: - develop # ============================================ # Stage 6: E2E tests on staging # ============================================ e2e-tests: stage: integration-tests script: - npm run test:e2e -- --base-url=https://staging.example.com artifacts: when: on_failure paths: - cypress/screenshots/ - cypress/videos/ only: - develop # ============================================ # Stage 7: Production deployment # ============================================ deploy-production: stage: deploy-production script: - kubectl set image deployment/app app=$DOCKER_IMAGE -n production - kubectl rollout status deployment/app -n production --timeout=300s environment: name: production url: https://app.example.com # Manual deployment with protection when: manual only: - main ``` This pipeline illustrates best practices: parallel stages for speed, artifacts for traceability, and protected environments for production. **Q4: How to manage secrets in a CI/CD pipeline?** Secrets management requires a multi-layered approach combining encryption, rotation, and the principle of least privilege. ```yaml # kubernetes-secrets-management.yaml # Approach 1: External Secrets Operator with HashiCorp Vault apiVersion: external-secrets.io/v1beta1 kind: ExternalSecret metadata: name: app-secrets namespace: production spec: refreshInterval: 1h # Automatic rotation secretStoreRef: name: vault-backend kind: ClusterSecretStore target: name: app-secrets creationPolicy: Owner data: # Reference to secret in Vault - secretKey: DATABASE_PASSWORD remoteRef: key: secret/data/production/database property: password - secretKey: API_KEY remoteRef: key: secret/data/production/api property: key --- # SecretStore configuration apiVersion: external-secrets.io/v1beta1 kind: ClusterSecretStore metadata: name: vault-backend spec: provider: vault: server: "https://vault.example.com" path: "secret" version: "v2" auth: kubernetes: mountPath: "kubernetes" role: "external-secrets" # Dedicated ServiceAccount with minimal permissions serviceAccountRef: name: external-secrets-sa ``` Recommended practices include: never store secrets in plain text in code, use dedicated secret managers (Vault, AWS Secrets Manager), and enable automatic rotation. Avoid CI/CD environment variables visible in logs. Always mask secrets with the CI platform's native features (masked variables). ## Kubernetes and Orchestration Kubernetes questions evaluate understanding of orchestration concepts and the ability to solve concrete problems. **Q5: Explain Kubernetes architecture and the role of each component.** Kubernetes follows a master-node architecture with components having distinct responsibilities. ```yaml # kubernetes-architecture.yaml # Control Plane components (Master) control_plane: api_server: role: "Entry point for all API requests" responsibilities: - "Validation and configuration of API objects" - "Authentication and authorization" - "REST interface for kubectl and other clients" etcd: role: "Distributed key-value database" responsibilities: - "Cluster state storage" - "Source of truth for configuration" - "Consensus via Raft algorithm" scheduler: role: "Assigning Pods to nodes" responsibilities: - "Evaluating constraints (resources, affinity)" - "Selecting the optimal node" - "Respecting PodDisruptionBudgets" controller_manager: role: "Control loops for desired state" controllers: - "ReplicaSet Controller" - "Deployment Controller" - "Service Controller" - "Node Controller" # Worker Node components worker_nodes: kubelet: role: "Agent on each node" responsibilities: - "Communication with Control Plane" - "Pod lifecycle management" - "Node status reporting" kube_proxy: role: "Network proxy on each node" responsibilities: - "iptables/IPVS rules for Services" - "Intra-cluster load balancing" container_runtime: role: "Container execution" options: - "containerd (recommended)" - "CRI-O" ``` This architecture enables high availability: the Control Plane can be replicated, and workloads are distributed across Worker Nodes. **Q6: How to debug a Pod that won't start?** Kubernetes debugging follows a methodical approach by analyzing different layers. ```bash # kubernetes-debugging.sh # Workflow for debugging a failing Pod # Step 1: Check Pod status kubectl get pod my-app-pod -o wide # STATUS: CrashLoopBackOff, ImagePullBackOff, Pending, etc. # Step 2: Pod details and events kubectl describe pod my-app-pod # Important sections: # - Conditions (PodScheduled, Initialized, Ready) # - Events (scheduling, pull errors, etc.) # Step 3: Container logs kubectl logs my-app-pod --previous # Previous crash logs kubectl logs my-app-pod -c init-container # Init container logs # Step 4: Interactive execution for debugging kubectl exec -it my-app-pod -- sh # Check: env vars, mounted files, network # Step 5: Check available resources kubectl describe node # Sections: Allocatable, Allocated resources # Step 6: Debug with ephemeral Pod (K8s 1.25+) kubectl debug my-app-pod -it --image=busybox --share-processes ``` Common causes include: insufficient resources, image not found, missing secrets, or misconfigured probes. ```yaml # pod-debugging-checklist.yaml # Debugging checklist by status debugging_by_status: Pending: causes: - "Insufficient resources on nodes" - "PersistentVolumeClaim not bound" - "Affinity/Taints not satisfied" commands: - "kubectl describe pod | grep -A 20 Events" - "kubectl get pvc" - "kubectl describe nodes | grep -A 5 Allocated" ImagePullBackOff: causes: - "Non-existent image or incorrect tag" - "Private registry without imagePullSecrets" - "Docker Hub rate limiting" commands: - "kubectl get events --field-selector reason=Failed" - "kubectl get secret -o yaml" CrashLoopBackOff: causes: - "Application error at startup" - "Missing configuration (env vars, configmaps)" - "Liveness probe too aggressive" commands: - "kubectl logs --previous" - "kubectl describe pod | grep -A 10 Liveness" OOMKilled: causes: - "Memory limit too low" - "Memory leak in application" commands: - "kubectl describe pod | grep -A 5 Last State" - "kubectl top pod " ``` ## Infrastructure as Code IaC questions evaluate mastery of provisioning tools and best practices. **Q7: Terraform vs Ansible: when to use each tool?** These tools have distinct philosophies and use cases. ```hcl # terraform-example.tf # Terraform: Infrastructure provisioning (declarative) # Ideal for: cloud resources, networking, infrastructure state terraform { required_providers { aws = { source = "hashicorp/aws" version = "~> 5.0" } } # Remote state for collaboration backend "s3" { bucket = "terraform-state-prod" key = "infrastructure/terraform.tfstate" region = "eu-west-1" dynamodb_table = "terraform-locks" encrypt = true } } # Declarative resource: Terraform manages the lifecycle resource "aws_eks_cluster" "main" { name = "production-cluster" role_arn = aws_iam_role.eks_cluster.arn version = "1.29" vpc_config { subnet_ids = module.vpc.private_subnets endpoint_private_access = true endpoint_public_access = false } # Implicit dependencies managed by Terraform depends_on = [ aws_iam_role_policy_attachment.eks_cluster_policy ] } # Reusable modules for standardization module "vpc" { source = "terraform-aws-modules/vpc/aws" version = "5.0.0" name = "production-vpc" cidr = "10.0.0.0/16" azs = ["eu-west-1a", "eu-west-1b", "eu-west-1c"] private_subnets = ["10.0.1.0/24", "10.0.2.0/24", "10.0.3.0/24"] public_subnets = ["10.0.101.0/24", "10.0.102.0/24", "10.0.103.0/24"] enable_nat_gateway = true single_nat_gateway = false # HA: one NAT per AZ } ``` ```yaml # ansible-example.yml # Ansible: Configuration management (procedural/declarative) # Ideal for: OS configuration, app deployment, orchestration --- - name: Configure application servers hosts: app_servers become: yes vars: app_version: "2.5.0" tasks: # System package management - name: Install required packages ansible.builtin.apt: name: - nginx - python3-pip - supervisor state: present update_cache: yes # Configuration via Jinja2 templates - name: Deploy nginx configuration ansible.builtin.template: src: templates/nginx.conf.j2 dest: /etc/nginx/sites-available/app owner: root group: root mode: '0644' notify: Reload nginx # Application deployment - name: Deploy application ansible.builtin.git: repo: "https://github.com/org/app.git" dest: /opt/app version: "v{{ app_version }}" notify: Restart application handlers: - name: Reload nginx ansible.builtin.service: name: nginx state: reloaded - name: Restart application ansible.builtin.supervisorctl: name: app state: restarted ``` In summary: Terraform for infrastructure (what exists), Ansible for configuration (how it's configured). Both tools are often combined in a complete workflow. **Q8: How to structure a Terraform project for a large organization?** A modular structure with environment separation facilitates maintenance and collaboration. ```bash # terraform-project-structure # Recommended structure for enterprise projects terraform-infrastructure/ ├── modules/ # Reusable modules │ ├── networking/ │ │ ├── main.tf │ │ ├── variables.tf │ │ ├── outputs.tf │ │ └── README.md │ ├── kubernetes/ │ │ ├── main.tf │ │ ├── variables.tf │ │ └── outputs.tf │ └── database/ │ ├── main.tf │ ├── variables.tf │ └── outputs.tf │ ├── environments/ # Per-environment configuration │ ├── dev/ │ │ ├── main.tf # Calls modules │ │ ├── variables.tf │ │ ├── terraform.tfvars # Dev values │ │ └── backend.tf # Dev state │ ├── staging/ │ │ ├── main.tf │ │ ├── terraform.tfvars │ │ └── backend.tf │ └── production/ │ ├── main.tf │ ├── terraform.tfvars │ └── backend.tf │ ├── shared/ # Shared resources │ ├── iam/ │ └── dns/ │ └── .github/ └── workflows/ └── terraform.yml # CI/CD pipeline ``` ```hcl # environments/production/main.tf # Example of module usage module "networking" { source = "../../modules/networking" environment = "production" vpc_cidr = var.vpc_cidr azs = var.availability_zones enable_flow_logs = true } module "kubernetes" { source = "../../modules/kubernetes" environment = "production" cluster_name = "prod-cluster" vpc_id = module.networking.vpc_id subnet_ids = module.networking.private_subnet_ids node_groups = var.node_groups # Production: HA configuration cluster_version = "1.29" enable_cluster_autoscaler = true } module "database" { source = "../../modules/database" environment = "production" vpc_id = module.networking.vpc_id subnet_ids = module.networking.database_subnet_ids instance_class = "db.r6g.xlarge" multi_az = true # HA in production backup_retention = 30 } ``` This structure enables: module versioning, change review per environment, and code reuse. ## Monitoring and Observability Monitoring questions evaluate the ability to design observable systems. **Q9: What are the three pillars of observability?** Observability relies on three complementary data types that help understand a system's internal state. ```yaml # observability-pillars.yaml # The three pillars of observability pillars: metrics: description: "Numeric data aggregated over time" characteristics: - "Low cardinality" - "Efficient storage" - "Ideal for alerting" examples: - "request_count (counter)" - "response_time_seconds (histogram)" - "active_connections (gauge)" tools: - "Prometheus" - "Datadog" - "CloudWatch" use_cases: - "Real-time dashboards" - "Threshold alerts" - "Capacity planning" logs: description: "Timestamped text events" characteristics: - "High cardinality" - "Detailed context" - "Large storage" examples: - "Application errors" - "Audit events" - "Debug information" tools: - "Loki" - "Elasticsearch" - "CloudWatch Logs" use_cases: - "Debugging" - "Audit compliance" - "Root cause analysis" traces: description: "Request tracking across services" characteristics: - "End-to-end view" - "Context propagation" - "Bottleneck identification" examples: - "Distributed transaction" - "Service dependencies" - "Latency breakdown" tools: - "Jaeger" - "Tempo" - "AWS X-Ray" use_cases: - "Performance optimization" - "Service dependencies" - "Error propagation" ``` **Q10: How to configure effective alerts?** Well-designed alerts reduce fatigue and enable rapid incident response. ```yaml # prometheus-alerting-rules.yaml # Prometheus alerting rules with best practices groups: - name: application-alerts rules: # Alert on symptom, not cause - alert: HighErrorRate # Error rate > 1% over 5 minutes expr: | sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) > 0.01 for: 5m # Avoid false positives labels: severity: critical team: backend annotations: summary: "High error rate detected" description: | Error rate is {{ $value | humanizePercentage }} for the last 5 minutes. runbook_url: "https://wiki.example.com/runbooks/high-error-rate" # Proactive alert on saturation - alert: DiskSpaceRunningLow expr: | (node_filesystem_avail_bytes / node_filesystem_size_bytes) * 100 < 20 for: 15m labels: severity: warning annotations: summary: "Disk space below 20%" description: | Node {{ $labels.instance }} has only {{ $value | humanize }}% disk space remaining. # SLO-based alerting - alert: SLOBudgetBurnRate # Error budget consumed too quickly expr: | ( sum(rate(http_requests_total{status=~"5.."}[1h])) / sum(rate(http_requests_total[1h])) ) > (1 - 0.999) * 14.4 for: 5m labels: severity: critical annotations: summary: "SLO budget burning too fast" description: | At current error rate, monthly SLO budget will be exhausted in less than 2 days. ``` ```yaml # alertmanager-config.yaml # AlertManager configuration with intelligent routing global: resolve_timeout: 5m route: receiver: default group_by: [alertname, cluster, service] group_wait: 30s # Wait to group alerts group_interval: 5m # Interval between grouped notifications repeat_interval: 4h # Re-alert if not resolved routes: # Critical alerts: immediate notification - match: severity: critical receiver: pagerduty-critical continue: true # Also notify Slack # Alerts by team - match: team: backend receiver: slack-backend - match: team: infrastructure receiver: slack-infra receivers: - name: pagerduty-critical pagerduty_configs: - service_key: severity: critical - name: slack-backend slack_configs: - channel: '#alerts-backend' send_resolved: true title: '{{ .Status | toUpper }}: {{ .CommonAnnotations.summary }}' text: '{{ .CommonAnnotations.description }}' ``` Key principles: alert on symptoms (user impact) rather than causes, include runbooks, and adjust thresholds according to SLOs. ## Security and Compliance Security questions evaluate understanding of risks and countermeasures. **Q11: How to secure a Kubernetes cluster?** Kubernetes security covers multiple layers: network, authentication, workloads, and data. ```yaml # kubernetes-security-policies.yaml # NetworkPolicy: network isolation between namespaces apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny-all namespace: production spec: # Applied to all pods in namespace podSelector: {} policyTypes: - Ingress - Egress # No traffic allowed by default ingress: [] egress: [] --- # Allow only necessary traffic apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: api-network-policy namespace: production spec: podSelector: matchLabels: app: api policyTypes: - Ingress - Egress ingress: # Accept only from ingress controller - from: - namespaceSelector: matchLabels: name: ingress-nginx ports: - protocol: TCP port: 8080 egress: # Allow to database - to: - podSelector: matchLabels: app: postgres ports: - protocol: TCP port: 5432 # Allow DNS - to: - namespaceSelector: {} podSelector: matchLabels: k8s-app: kube-dns ports: - protocol: UDP port: 53 ``` ```yaml # pod-security-standards.yaml # PodSecurity: workload restrictions apiVersion: v1 kind: Namespace metadata: name: production labels: # Enforce: blocks violations pod-security.kubernetes.io/enforce: restricted # Warn: warns without blocking pod-security.kubernetes.io/warn: restricted # Audit: logs violations pod-security.kubernetes.io/audit: restricted --- # Pod compliant with "restricted" standards apiVersion: v1 kind: Pod metadata: name: secure-pod namespace: production spec: securityContext: runAsNonRoot: true runAsUser: 1000 fsGroup: 1000 seccompProfile: type: RuntimeDefault containers: - name: app image: myapp:latest securityContext: allowPrivilegeEscalation: false readOnlyRootFilesystem: true capabilities: drop: - ALL resources: limits: memory: "256Mi" cpu: "500m" requests: memory: "128Mi" cpu: "250m" volumeMounts: - name: tmp mountPath: /tmp volumes: - name: tmp emptyDir: {} ``` Kubernetes security combines multiple layers: RBAC for authorization, NetworkPolicies for network isolation, PodSecurity for workload restrictions, and encryption of secrets at rest. **Q12: What is the principle of least privilege and how to apply it?** This principle states that a user or system should only have the minimum permissions necessary to accomplish their task. ```yaml # rbac-least-privilege.yaml # Kubernetes RBAC with minimal permissions # Role: permissions in a specific namespace apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: production name: deployment-manager rules: # Pod reading (for monitoring) - apiGroups: [""] resources: ["pods", "pods/log"] verbs: ["get", "list", "watch"] # Deployment management only - apiGroups: ["apps"] resources: ["deployments"] verbs: ["get", "list", "watch", "update", "patch"] # No create/delete on deployments # No access to secrets or sensitive configmaps --- # RoleBinding: Role <-> ServiceAccount association apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: deployment-manager-binding namespace: production subjects: - kind: ServiceAccount name: ci-cd-deployer namespace: production roleRef: kind: Role name: deployment-manager apiGroup: rbac.authorization.k8s.io --- # Dedicated ServiceAccount for CI/CD apiVersion: v1 kind: ServiceAccount metadata: name: ci-cd-deployer namespace: production annotations: # Automatic token expiration kubernetes.io/enforce-mountable-secrets: "true" ``` This principle also applies to AWS IAM, databases, and network access. ## SRE and Reliability SRE questions evaluate understanding of reliability practices and incident management. **Q13: What is an SLO and how to define it?** Service Level Objectives (SLOs) quantify the expected reliability of a service and guide engineering decisions. ```yaml # slo-definitions.yaml # SLO definitions for an API service service: payment-api owner: payments-team slos: - name: availability description: "Service responds successfully to requests" sli: # SLI: measured metric type: availability good_events: "http_requests_total{status=~'2..'}" total_events: "http_requests_total" target: 99.9% # SLO: objective window: 30d # Measurement window # Error budget: 0.1% = 43.2 minutes/month error_budget: monthly_minutes: 43.2 - name: latency description: "Response time below threshold" sli: type: latency good_events: "http_request_duration_seconds_bucket{le='0.3'}" total_events: "http_request_duration_seconds_count" target: 99% # 99% of requests < 300ms window: 30d - name: throughput description: "Ability to process transactions" sli: type: throughput query: "sum(rate(transactions_processed_total[5m]))" target: ">= 1000 TPS" # Actions based on error budget error_budget_policy: - condition: "remaining > 50%" actions: - "Feature development prioritized" - "Experimentation allowed" - condition: "remaining 20-50%" actions: - "Balance features and reliability" - "Increase testing coverage" - condition: "remaining < 20%" actions: - "Freeze non-critical deployments" - "Focus on reliability improvements" - condition: "exhausted" actions: - "Incident response mode" - "All hands on reliability" ``` SLOs enable objective decisions: deploy a new feature vs strengthen reliability. **Q14: How to conduct an effective post-mortem?** A blameless post-mortem promotes learning and prevention of future incidents. ```yaml # postmortem-template.yaml # Blameless post-mortem template incident: id: "INC-2026-0042" title: "Payment service unavailability" severity: SEV1 duration: "45 minutes" date: "2026-01-15" # Factual timeline timeline: - time: "14:32" event: "Alert: error rate > 5% on payment-api" actor: "PagerDuty" - time: "14:35" event: "Incident declared, team notified" actor: "On-call engineer" - time: "14:42" event: "Cause identified: connection pool exhausted" actor: "Backend team" - time: "14:55" event: "Mitigation: deployment rollback" actor: "Backend team" - time: "15:17" event: "Service restored, monitoring stable" actor: "Backend team" # Measurable impact impact: users_affected: 12500 transactions_failed: 847 revenue_impact: "~$16,500" slo_budget_consumed: "2.3 days" # Root cause analysis (5 Whys) root_cause_analysis: - question: "Why was the service unavailable?" answer: "DB connections were exhausted" - question: "Why were connections exhausted?" answer: "A slow query was blocking connections" - question: "Why was there a slow query?" answer: "Missing index on a new table" - question: "Why was the index missing?" answer: "Incomplete migration deployed" - question: "Why was the migration incomplete?" answer: "No execution plan validation in staging" # Corrective actions action_items: - id: "AI-001" type: "prevent" description: "Add SQL execution plan validation in CI" owner: "DBA team" due_date: "2026-01-22" priority: P1 - id: "AI-002" type: "detect" description: "Alert on connection pool usage > 80%" owner: "SRE team" due_date: "2026-01-18" priority: P1 - id: "AI-003" type: "mitigate" description: "Implement circuit breaker on DB queries" owner: "Backend team" due_date: "2026-01-29" priority: P2 # Lessons learned lessons_learned: what_went_well: - "Fast detection thanks to alerting (< 3 min)" - "Clear communication in incident channel" - "Rollback completed in less than 15 minutes" what_went_poorly: - "No load testing on new endpoint" - "Staging didn't reflect prod data volume" lucky: - "Incident during daytime with full team available" ``` The goal is to improve the system, not find someone to blame. Actions are classified into three categories: prevention, detection, and mitigation. ## Conclusion DevOps interviews cover a broad spectrum of skills, from culture to technical tools. The key to success lies in demonstrating deep understanding of concepts, illustrated by concrete implementation examples. ### Preparation checklist - ✅ Master CI/CD concepts and be able to design a complete pipeline - ✅ Understand Kubernetes architecture and be able to debug common problems - ✅ Know IaC tools (Terraform, Ansible) and their respective use cases - ✅ Know how to configure monitoring and define relevant alerts - ✅ Apply security best practices (least privilege, defense in depth) - ✅ Explain SRE practices (SLOs, error budgets, post-mortems) - ✅ Have concrete problem-solving examples - ✅ Be able to explain complex concepts simply