What a DevOps engineer
actually does

1 What DevOps actually does

The textbook definition (“a culture that unites development with operations”) doesn't help you in an interview, because it doesn't say what you do on Monday morning. Here's a phrasing that helps:

The role has four pillars. All four show up in job postings, in different orders:

What DevOps is NOT

• It's not “the person who has access to production.” Access is a consequence, not the role. A good DevOps engineer reduces the number of people who have to go into servers manually, including themselves.
• It's not a sysadmin with a new name. A sysadmin administers existing servers. DevOps creates them from code, destroys them, recreates them identically. If a server can't be recreated from scratch automatically, it isn't built right.
• It doesn't write the product's functionality. It writes code, but automation code: pipelines, manifests, infrastructure modules, scripts.
• It's not a separate team that receives tickets. When it becomes that, you've reinvented exactly the wall DevOps was supposed to tear down.

Why the role appeared

Historically, there were two teams with opposite goals. Development was paid to change things. Operations was paid to keep nothing changing, because any change could bring production down. The result: rare, large, risky releases, every two or three months, at night, with everyone in a meeting.

The DevOps answer is counterintuitive: you ship more often, not less. A small, automated release of twenty lines is easy to verify and easy to roll back. A release with three months of work behind it can be neither verified nor rolled back. The risk doesn't come from frequency, it comes from size.

2 A DevOps engineer's day

This is what shows up consistently in role descriptions and in accounts from people in the field. It's not a typical day — it's a mix that changes daily, and getting interrupted is part of the job.

3 The big picture: from commit to production

If you keep one single image from this page, let it be this one. Every chapter that follows explains one box from the diagram below.

4 Git and the workflow

Git is where the truth lives. Everything that follows — pipeline, image, release — starts from a commit. If it's not in Git, it doesn't exist.

Two branching models

GitOps — the idea that ties Git to Kubernetes

In GitOps, the cluster's desired state lives in a Git repository, and an agent running in the cluster (Argo CD or Flux) continuously compares what's in Git with what's in the cluster and corrects the difference. Practical consequences:

• Nobody runs kubectl apply manually in production anymore. You change the file, open a PR, it gets approved, the agent applies it.
• If someone changes something directly on the cluster, the agent reverts it — the drift self-corrects.
• Rolling back to the previous version is a git revert. The release history is the Git history.

5 CI/CD — the concepts

The three letters that get mixed up

The stages of a pipeline, in order

Deployment strategies

6 GitHub Actions, in detail

It's the automation system built into GitHub. It runs on machines that GitHub provides (a “runner”), triggered by events in the repository. It's become the default choice for most new teams, and it's what most job postings ask for.

6.1 The vocabulary, from big to small

6.2 A complete workflow, commented line by line

# The name that shows up in the Actions tab
name: Build and deploy

# ---- WHEN it runs ----
on:
  push:
    branches: [main]          # only on main
    paths:                    # and only if something relevant changed
      - 'src/**'
      - 'Dockerfile'
  pull_request:              # and on every PR, to catch issues early
  workflow_dispatch:         # plus a manual button in the UI

# ---- Permissions: the minimum needed, explicit ----
permissions:
  contents: read            # can read the code
  id-token: write          # can request an OIDC token (for the cloud, no passwords)

# ---- Only one run per branch; the old one gets canceled ----
concurrency:
  group: deploy-${{ github.ref }}
  cancel-in-progress: true

env:
  IMAGE: ghcr.io/${{ github.repository }}

jobs:

  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:                 # same job, on 3 Node versions, in parallel
        node: [18, 20, 22]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node }}
          cache: npm          # keeps dependencies between runs = faster build
      - run: npm ci
      - run: npm test

  build:
    needs: test                # only starts if “test” passed
    runs-on: ubuntu-latest
    outputs:
      tag: ${{ steps.meta.outputs.tag }}
    steps:
      - uses: actions/checkout@v4
      - id: meta
        run: echo "tag=${GITHUB_SHA::7}" >> $GITHUB_OUTPUT
      - uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      - uses: docker/build-push-action@v6
        with:
          push: true
          tags: ${{ env.IMAGE }}:${{ steps.meta.outputs.tag }}

  deploy:
    needs: build
    if: github.ref == 'refs/heads/main'   # we do NOT deploy from PRs
    runs-on: ubuntu-latest
    environment: production    # this is where human approval is required
    steps:
      - uses: google-github-actions/auth@v2
        with:
          workload_identity_provider: ${{ secrets.WIF_PROVIDER }}
          service_account: ${{ secrets.GCP_SA }}
      - run: |
          kubectl set image deployment/api \
            api=${{ env.IMAGE }}:${{ needs.build.outputs.tag }} -n prod
          kubectl rollout status deployment/api -n prod --timeout=180s

6.3 Secrets and authentication

Three levels, in the order they're looked up: organization (shared across multiple repositories), repository, environment (the most restricted — they only exist in jobs that declare environment:). Environment secrets are the safest for production, because they can be tied to approvers.

What you need to know:

• Secrets are encrypted and hidden in logs, but a step that runs arbitrary code can extract them. That's why it matters which steps you hand them to.
• They're not automatically passed to workflows in other repositories (forks) — that's the protection against a malicious PR.
• secrets.GITHUB_TOKEN is generated automatically for every run and expires at the end. Set it to “read-only” by default at the organization level, and explicitly request more with permissions:.

OIDC — how you get rid of keys completely

The old way: you put an AWS_SECRET_ACCESS_KEY in the repository's secrets. The key is permanent; if it leaks, it stays valid until you rotate it manually. The current, recommended way: OpenID Connect. The workflow requests a short-lived token from GitHub that describes who it is (“repository X, branch main”), and the cloud is configured to trust GitHub and hand out a temporary role in exchange for that token. No password sits anywhere anymore.

6.4 The security of external actions

• Pin to a hash, not a tag. uses: some/action@v3 means “whatever is currently in v3” — and the author can move the tag onto new code. uses: some/action@a81bbbf... means exactly that code. You let Dependabot propose the updates.
• Avoid pull_request_target unless you know exactly what you're doing. Unlike pull_request, it runs with the repository's secrets and with write permissions, in the context of the PR — including one that came from a stranger.
• Don't put PR data directly into run:. A PR title that contains shell characters becomes executed code. Pass the value through an environment variable and use the variable.

6.5 Reuse: two different mechanisms

6.6 Troubleshooting

• Add the repository secret ACTIONS_STEP_DEBUG=true and the logs become much more detailed.
• A job that “doesn't start” almost always has a false if: condition or a paths: filter that didn't match — not a bug.
• “Works locally, doesn't work in CI” usually means a dependency installed on your machine but missing on the clean runner, or an environment variable that only exists on your side.
• For a slow run, look at caching first: without actions/cache or without cache: in the setup action, you reinstall everything every time.

7 Jenkins and Azure DevOps — what you already have

Jenkins is the classic automation system, dating back to 2011, installed on your own servers. It has a controller and agents that execute the work. The major difference from GitHub Actions: Jenkins is an application you administer yourself — with plugins, updates, backups — while Actions is a service.

7.1 Anatomy of a Jenkinsfile

pipeline {
  agent { label 'linux-docker' }        // which agent runs this

  environment {                           // variables for the whole pipeline
    IMAGE = "registry.intern/api"
    REG   = credentials('registry-creds') // secret from Jenkins Credentials
  }

  triggers { pollSCM('H/5 * * * *') }    // or webhook from Git

  stages {
    stage('Build') {
      steps { sh 'mvn -B clean package' }
    }
    stage('Test') {
      steps { sh 'mvn test' }
      post { always { junit 'target/surefire-reports/*.xml' } }
    }
    stage('Image') {
      steps { sh "docker build -t $IMAGE:${GIT_COMMIT} ." }
    }
    stage('Deploy green') {
      steps { sh './deploy.sh green' }
    }
    stage('Switch traffic') {
      input { message 'Switch traffic to green?' }  // human approval
      steps { sh './switch.sh green' }
    }
  }

  post {
    failure { mail to: 'team@company.com', subject: "Pipeline failed: ${env.JOB_NAME}" }
    always  { cleanWs() }
  }
}

7.2 Translating Jenkins → GitHub Actions

If they ask you “have you worked with GitHub Actions?”, the right answer isn't yes or no. It's to show you know the mapping between the two — because that's exactly what someone doing a migration does, and migration is a task that comes up often in job postings.

7.3 Azure DevOps, in brief

The Microsoft suite: Repos (Git), Pipelines (CI/CD), Boards (tickets), Artifacts (packages), Test Plans. The pipelines are YAML, similar in shape to Actions: trigger, pool, stages, jobs, steps. What's specific: service connection (the identity the pipeline uses to enter Azure), variable group (shared variables, optionally linked to Key Vault), environment with approvals and checks — the equivalent of a production gate.

8 Docker and containers

8.1 What a container actually is

A container is an ordinary process on the host machine, which sees only a slice of the system: its own filesystem, its own network, its own process list. The isolation is done by the Linux kernel (namespaces and cgroups). It doesn't have its own kernel — it uses the host's.

8.2 Image and container

The image is the template: an immutable package with the application and everything it needs. The container is an instance running from that image. One image, any number of containers. The analogy worth remembering: the image is the class, the container is the object.

8.3 Layers and why the order matters

Every instruction in the Dockerfile creates a layer. Layers get cached and reused — but when a layer changes, everything after it gets rebuilt. Hence the practical rule: put what rarely changes first.

FROM node:20
WORKDIR /app
COPY . .           # any file that changed
RUN npm install    # invalidates this
CMD ["node","server.js"]

FROM node:20
WORKDIR /app
COPY package*.json ./   # rarely changes
RUN npm ci
COPY . .               # changes often, but it's last
CMD ["node","server.js"]

8.4 Multi-stage builds

You build in a large image, with a compiler and tools, then copy just the result into a small image. The final image doesn't contain the compiler, so it's smaller and has a reduced attack surface.

# --- stage 1: build ---
FROM golang:1.23 AS build
WORKDIR /src
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 go build -o /out/api ./cmd/api

# --- stage 2: run ---
FROM gcr.io/distroless/static:nonroot
COPY --from=build /out/api /api
USER nonroot:nonroot      # do NOT run as root
EXPOSE 8080
ENTRYPOINT ["/api"]

8.5 Security rules for images

• Don't run as root. By default, the process inside the container is root. If someone breaks out of the container, they break out as root.
• Read-only filesystem for the main process, plus volumes for whatever actually needs to be written.
• Don't put secrets in the image. Even if you delete them in a later layer, the layer where they were added still exists and can be extracted. Secrets get injected at runtime.
• Pin base image versions. FROM node:20.11.1-alpine, not FROM node:latest — otherwise today's build differs from yesterday's.
• Scan the image (Trivy, Grype) as a pipeline step.

8.6 What gets lost when the container dies

The container's filesystem is ephemeral: it disappears along with the container. Whatever needs to survive goes into a volume or an external service (database, object storage). Logs get written to standard output, not to files inside the container — the platform collects them.

9 Kubernetes — fundamentals

9.1 The problem it solves

You have fifty containers that need to run on twenty machines. Who decides which machine each one goes on? What happens when a machine dies at three in the morning? How do you route traffic to containers that come and go and change address? How do you ship a new version without stopping the service? Kubernetes is the answer to all of that, in one package.

9.2 The core idea: desired state and reconciliation

9.3 Cluster architecture

10 Kubernetes — the objects

10.1 Pod

The smallest unit Kubernetes can schedule on a node. It holds one or more containers that share the same IP address, the same ports, and can share volumes — containers inside a pod can see each other on localhost. In practice, one main container, plus maybe a helper one (sidecar): a log collector, a network proxy.

A pod is disposable. It doesn't get repaired: it gets deleted and another one gets created, with a different IP. That's also why you never connect directly to a pod's IP, but to a Service instead.

10.2 Deployment

The object you work with daily. You tell it which image, how many copies and how to do the update; it creates a ReplicaSet, which creates the pods. For every new version it creates a new ReplicaSet and scales down the old one — that's also where the ability to roll back comes from.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
  namespace: prod
spec:
  replicas: 3                 # how many copies I want
  selector:
    matchLabels: { app: api }  # which pods belong to me
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1             # I'm allowed 1 extra pod during the rollout
      maxUnavailable: 0       # but NONE fewer → zero downtime
  template:                    # from here down is the pod recipe
    metadata:
      labels: { app: api }
    spec:
      containers:
        - name: api
          image: registry/api:9f2c1ab   # NOT “latest”: you want to know what's running
          ports: [{ containerPort: 8080 }]
          env:
            - name: DB_HOST
              valueFrom:
                configMapKeyRef: { name: api-config, key: db_host }
            - name: DB_PASS
              valueFrom:
                secretKeyRef: { name: api-secret, key: db_pass }
          resources:
            requests: { cpu: "200m", memory: "256Mi" }  # for scheduling
            limits:   { cpu: "1",    memory: "512Mi" }  # ceiling at runtime
          readinessProbe:                            # can I receive traffic?
            httpGet: { path: /ready, port: 8080 }
            initialDelaySeconds: 5
            periodSeconds: 5
          livenessProbe:                             # am I still alive?
            httpGet: { path: /healthz, port: 8080 }
            initialDelaySeconds: 20
            periodSeconds: 10

10.3 Service — the four types

The Service finds pods through labels (selector), not by name. If you change the label on the pod and forget the selector, the Service is left with no endpoints and you get a connection error even though every pod is running fine. It's one of the most common causes of “it works on pod X, it doesn't work through the service.”

10.4 Ingress

A LoadBalancer Service per application gets expensive and hard to manage. Ingress is the layer on top: a single entry point, which routes by domain name and path to different internal services, and terminates TLS in one place. It needs an ingress controller installed in the cluster (nginx, Traefik, the provider's own) — the Ingress object by itself does nothing.

10.5 ConfigMap and Secret

Configuration doesn't go into the image. It goes into a ConfigMap (regular settings) or a Secret (passwords, keys, certificates) and gets injected into the pod, either as environment variables or as mounted files.

10.6 The other workload types

10.7 Storage

Three related objects: PersistentVolume (the actual disk), PersistentVolumeClaim (the application's request: “I want 20 GB, fast”) and StorageClass (the recipe that automatically creates the disk at the provider). In practice you only write the PVC; the rest resolves itself. Worth remembering: a disk in the cloud is usually tied to a zone — a pod that needs it can only be scheduled in that zone.

11 Delivery and health: the two things that get asked most

11.1 Rolling update, step by step

# update the image
kubectl set image deployment/api api=registry/api:9f2c1ab -n prod

# watch — exits non-zero if it doesn't succeed within 180s
kubectl rollout status deployment/api -n prod --timeout=180s

# revision history
kubectl rollout history deployment/api -n prod

# roll back to the previous version
kubectl rollout undo deployment/api -n prod

# roll back to a specific revision
kubectl rollout undo deployment/api --to-revision=4 -n prod

# clean restart, no image change (useful after changing a Secret)
kubectl rollout restart deployment/api -n prod

11.2 Probes — the three types and what they're for

11.3 Graceful shutdown

When a pod is stopped, Kubernetes does two things in parallel: it removes the pod from the Service's list of endpoints and sends SIGTERM to the process. Because these happen in parallel, there's a window of a few hundred milliseconds where the pod is still receiving new requests but has already started shutting down. The standard fix is a preStop hook that waits a few seconds before shutdown, plus an application that handles SIGTERM properly: it stops accepting new connections, finishes what it's already working on, then exits. terminationGracePeriodSeconds (default 30) is how much patience Kubernetes gives it; after that comes SIGKILL.

12 Resources and scaling

12.1 requests and limits

12.2 The three kinds of scaling

12.3 Where pods land — placement

• nodeSelector / nodeAffinity — “only place this pod on GPU nodes” or “preferably in zone A”.
• podAntiAffinity — “don't put two copies of the same service on the same node”. Without this, all three replicas can end up on a single node, and one node going down means the service goes down.
• topologySpreadConstraints — spreads pods evenly across availability zones.
• taints and tolerations — the reverse mechanism: the node rejects everything except pods that explicitly “tolerate” it. This is how you reserve nodes for special workloads.
• PodDisruptionBudget — “at least two pods available at all times”. Protects you during planned operations, like node upgrades.

13 Security in the cluster

13.1 RBAC — who's allowed to do what

Four objects, two pairs. Role grants permissions within a single namespace; ClusterRole across the whole cluster. RoleBinding and ClusterRoleBinding tie the role to someone: a user, a group, or a ServiceAccount (the identity a pod runs as).

kind: Role
metadata: { namespace: team-a, name: developer }
rules:
  - apiGroups: [""]
    resources: [pods, pods/log, services, configmaps]
    verbs: [get, list, watch]          # read-only
  - apiGroups: [apps]
    resources: [deployments]
    verbs: [get, list, watch, patch]   # can change the image, cannot delete

The command you use to check: kubectl auth can-i delete pods --as=ana -n prod.

13.2 Pod Security Admission

PodSecurityPolicy was deprecated in version 1.21 and removed in 1.25. The built-in replacement is Pod Security Admission: you put a label on the namespace and the cluster rejects pods that don't meet that level.

It applies in three modes: enforce (reject), audit (log it) and warn (warn the user). The usual adoption path is to start with warn, see what would break, and then switch to enforce. For more complex rules, people use OPA Gatekeeper or Kyverno.

13.3 NetworkPolicy

By default, in Kubernetes any pod can talk to any pod, in any namespace. It's the most surprising default in the whole system, and a good answer to “what would you improve in a legacy cluster”. NetworkPolicy changes that: you describe what traffic is allowed, and everything else is blocked. One catch: it only has an effect if the network plugin supports it (Calico, Cilium; some simple setups silently ignore it).

13.4 A namespace is not a security boundary

13.5 The rest of the hygiene checklist

• Disable automatic mounting of the ServiceAccount token in pods that don't talk to the API (automountServiceAccountToken: false).
• Encrypt etcd at rest, or keep secrets in an external vault.
• Don't use :latest. You can't know what's actually running, and you can't reproduce an issue.
• Scan images in the pipeline and block on critical vulnerabilities.
• Keep the API audit log turned on. It's the only source that tells you who changed what.

14 Cluster troubleshooting — the most-asked part

In 2026 Kubernetes interviews, “what is a pod”-type questions are just the warm-up. The part that matters is the scenario: “you’re told the service is down, what do you do?”. They’re testing the method, not the memorization.

14.1 The order you investigate in

# 1. What state are the pods in? (this gets you 60% of the answer)
kubectl get pods -n prod -o wide

# 2. Why is it in that state? Look at EVENTS, at the end of the output.
kubectl describe pod api-7d9f-x2k -n prod

# 3. What is the app saying?
kubectl logs api-7d9f-x2k -n prod
kubectl logs api-7d9f-x2k -n prod --previous   # the DEAD container's logs — essential for CrashLoop

# 4. What happened recently in the whole namespace?
kubectl get events -n prod --sort-by=.lastTimestamp | tail -30

# 5. Does the service have endpoints? (empty list = wrong selector or pods not ready)
kubectl get endpoints api -n prod

# 6. From inside a pod: DNS and connectivity
kubectl exec -it api-7d9f-x2k -n prod -- sh
  nslookup api.prod.svc.cluster.local
  wget -qO- http://api:8080/healthz

# 7. Actual consumption
kubectl top pods -n prod
kubectl top nodes

# 8. Are the nodes healthy?
kubectl get nodes
kubectl describe node nod-3 | grep -A5 Conditions

14.2 The diagnostic table

14.3 A network troubleshooting path, start to finish

“Service A can’t reach service B.” The order that finds the problem without guessing:

1. kubectl get pods -l app=b — do the pods exist and are they READY? A pod that isn’t ready isn’t in service.
2. kubectl get endpoints b — is the list empty? Then the service’s selector doesn’t match the pods’ labels. That’s the most common cause.
3. From pod A: nslookup b.namespace.svc.cluster.local — if DNS doesn’t answer, the problem is CoreDNS, not your service.
4. From pod A: wget -qO- http://b:8080/ — if DNS works but the connection is refused, check the port: the port in the Service must match the targetPort and the app’s actual port.
5. kubectl get networkpolicy -n namespace — is there a policy blocking it? If it’s the first policy in the namespace, it flipped the default from “everything allowed” to “only what’s written.”

15 Terraform and infrastructure as code

15.1 The idea

Infrastructure isn’t created by hand from the cloud console. It’s described in files, the files live in Git, and the tool applies the difference between what’s written and what exists. The consequences: environments are reproducible, changes go through review like any code, and there’s a history of the reasons behind them.

15.2 The cycle

15.3 State — the subject that separates people

Terraform keeps a state file that ties what you wrote to what exists in reality. Without it, it doesn’t know whether to create or modify.

• The state doesn’t live locally. It lives in a shared store (S3 with DynamoDB locking, an Azure Storage container, GCS), otherwise two colleagues applying at the same time step on each other’s state.
• Locking is mandatory. Two apply runs in parallel on the same state can corrupt it.
• The state contains secrets in plain text. The password of a database created by Terraform shows up in the state file. So: encryption, restricted access, and never in Git.
• Drift happens when someone changes something manually in the console. terraform plan shows it. The technical fix is import or realignment; the real fix is organizational — you remove manual write access to production.

terraform {
  required_version = "~> 1.9"
  backend "s3" {                    # the state, remote and lockable
    bucket         = "tf-state-company"
    key            = "prod/network.tfstate"
    region         = "eu-central-1"
    dynamodb_table = "tf-locks"
    encrypt        = true
  }
  required_providers {
    aws = { source = "hashicorp/aws", version = "~> 5.60" }
  }
}

variable "environment" {
  type    = string
  default = "prod"
}

module "network" {                     # module = reuse across environments
  source = "./modules/network"
  environment = var.environment
  cidr   = "10.20.0.0/16"
}

resource "aws_db_instance" "main" {
  identifier        = "db-${var.environment}"
  engine            = "postgres"
  instance_class    = "db.t4g.medium"
  allocated_storage = 50
  lifecycle {
    prevent_destroy = true            # safety net: can't be deleted by mistake
  }
}

output "db_endpoint" {
  value = aws_db_instance.main.endpoint
}

16 Cloud: what you need to know from each one

You don’t need a certification to answer at an interview. You need the map of the core services and the equivalences, because job posts ask for “AWS or Azure or GCP,” and whoever knows one can learn the other.

Cost, the topic that comes up at senior level

A senior DevOps engineer gets asked about cost, because it’s a real lever. The main sources of waste and what you do about them:

• Resources reserved far above actual consumption. Fixed by measuring actual usage and adjusting requests. This is usually where the biggest savings are.
• Test environments running at night and on weekends. Shut them down on a schedule.
• Orphaned disks and IP addresses left behind after the resources that used them were deleted.
• Cross-availability-zone traffic, which gets billed and which nobody notices until they look at the invoice.
• Tagging by team and environment, otherwise the bill can’t be attributed to anyone and nobody optimizes it.

17 Monitoring, Logs and SLOs

17.1 The three pillars

17.2 What actually gets monitored

Two sets of rules that get quoted a lot:

17.3 SLI, SLO, SLA and the error budget

17.4 Alerts

The most common problem on real teams isn’t too few alerts, it’s too many. When you get forty alerts a day and thirty-nine of them don’t need anything, you stop reading them — and you miss the fortieth one. The rules that fix it:

• Alert on symptom, not cause. “Error rate went above the threshold” is useful. “CPU at 90%” isn’t — it might be perfectly normal.
• Every alert that fires at night has to require immediate human action. If it can wait until morning, it’s not an alert, it’s a ticket.
• Every alert has a runbook — a short document that says what to check and what to do.
• Alert on the rate at which the error budget is being consumed, not on every spike.

17.5 Tools

Prometheus collects metrics by pulling them periodically from applications and is queried with PromQL. Grafana draws them. Alertmanager routes alerts and groups them. Loki or ELK for logs. Jaeger or Tempo for traces. OpenTelemetry is the instrumentation standard that feeds all of them. The commercial alternative that does all of it in one product: Datadog, New Relic, Dynatrace.

18 Incidents and On-Call

18.1 Roles in a major incident

• Incident commander — coordinates, doesn’t troubleshoot. Makes the decisions and keeps order.
• Communications lead — updates stakeholders and customers at fixed intervals, so no one interrupts the technical team to ask “how’s it going.”
• The people fixing it — actually look at the system.
• The scribe — records the timeline with exact times. Without it, the postmortem is a discussion from memory.

On small teams, one person can wear several hats. What you never do: have the commander also get hands-on in the system, because then no one has the overall picture.

18.2 The blameless postmortem

The principle: people aren’t the cause; the system that allowed the mistake is. If a wrong command could delete production, the problem isn’t the person who typed it, it’s that the system accepted it without confirmation, without a blast-radius limit, and without a way back. If a name shows up in the postmortem instead of a systemic cause, people will hide incidents next time, and you lose exactly the information you needed.

Document structure: summary, impact (who, how long, what broke), timeline with times, contributing causes (plural), what went well, what went wrong, actions with an owner and a deadline. Without that last section, it’s just literature.

19 Security in the Pipeline (DevSecOps)

The idea in one sentence: security checks move earlier into the development process, where they’re cheap, instead of being an audit at the end.

Software supply chain

A topic that’s come up more and more after the last few years’ incidents. The main points: pin actions and images to a hash, not a tag; sign artifacts and verify the signature on delivery; generate an SBOM so you know within five minutes whether you’re affected by a new vulnerability; give the pipeline minimal permissions, obtained through OIDC instead of permanent keys.

20 Bash and Python

Almost every job posting asks for “scripting.” You’re not being asked to be a programmer: you’re being asked to automate something repetitive and not cause damage when the script fails halfway through.

20.1 The header that saves you

#!/usr/bin/env bash
set -euo pipefail
# -e  : stop at the first command that fails
# -u  : error when using an undefined variable (catches typos)
# -o pipefail : a pipeline fails if ANY element fails, not just the last one

IFS=$'\n\t'                  # no longer split on spaces — protects paths with spaces

# guaranteed cleanup, whatever happens
TMP=$(mktemp -d)
trap 'rm -rf "$TMP"' EXIT

# required argument, with a clear message if it's missing
ENVIRONMENT=${1:?usage: $0 <environment>}

log() { printf '%s [%s] %s\n' "$(date +%FT%T)" "$1" "$2" >&2; }

# retry with increasing backoff — mandatory for any network call
retry() {
  local n=0 max=5 delay=2
  until "$@"; do
    n=$((n+1))
    [ "$n" -ge "$max" ] && { log ERROR "failed after $max attempts: $*"; return 1; }
    log WARN "attempt $n failed, retrying in ${delay}s"
    sleep "$delay"; delay=$((delay*2))
  done
}

retry curl -fsS "https://api.internal/$ENVIRONMENT/status" > "$TMP/status.json"
log INFO "done"

20.2 When you switch to Python

The practical rule: Bash up to a hundred lines or until you start parsing serious JSON; past that, Python. Signs you’ve outgrown it: you need data structures, error handling for different cases, HTTP calls with headers and retries, tests.

import os, sys, json, logging
import requests
from tenacity import retry, stop_after_attempt, wait_exponential

logging.basicConfig(level=logging.INFO, format="%(asctime)s %(levelname)s %(message)s")

TOKEN = os.environ["API_TOKEN"]      # from env, NOT from code

@retry(stop=stop_after_attempt(5), wait=wait_exponential(min=1, max=30))
def get_status(environment: str) -> dict:
    r = requests.get(f"https://api.internal/{environment}/status",
                     headers={"Authorization": f"Bearer {TOKEN}"},
                     timeout=10)          # timeout ALWAYS — otherwise it hangs forever
    r.raise_for_status()
    return r.json()

if __name__ == "__main__":
    try:
        print(json.dumps(get_status(sys.argv[1]), indent=2))
    except Exception as e:
        logging.error("could not read status: %s", e)
        sys.exit(1)                        # correct exit code, so the pipeline knows

20.3 Linux — the order you investigate a server in

21 Your experience, translated into the language of the role

This is the section you need most. You’re not short on experience — you’re short on the habit of naming it in the words the person across from you is listening for. Someone who kept production up at Metro and migrated message queues at Volvo has exactly the background the DevOps role is built on; if he tells it with 2012’s terms, the listener hears “system administrator,” not “reliability engineer.”

21.1 Where you’re on solid ground and where you’ll be pushed

22 Learning plan

You don’t need to know everything. You need what you say to be backed by something you’ve touched with your own hands. The plan below is built on that: every block ends with something that exists on your machine and that you can talk about in the past tense.

Certifications, if you want something on paper

CKA (Certified Kubernetes Administrator) is the best regarded of all of them, because it’s a hands-on exam — you sit at a terminal and solve things. KCNA is the entry-level version, questions only. Terraform Associate is cheap and quick. Vendor certifications (AWS, Azure, Google Cloud) matter mostly when the company runs on that provider. No certification replaces a cluster you broke and fixed, but CKA gets past the automated screening filters, which is a real and separate problem.

23 Glossary

Terms that come up in conversation and are assumed to be known. If one of them stops you mid-interview, you’ve lost the thread of the sentence — that’s why they’re here.