DevOps Engineer

Run, secure and debug a Linux server, and explain how a request travels from a browser to your app.

• Shell and Filesystem

  Core

  Almost every server you will manage runs Linux, so moving around it quickly from a terminal is the skill everything else builds on.

  • Navigate with cd, ls and pwd
  • Filesystem layout: /etc, /var, /home
  • Pipes and redirection
  • Search with grep and find
  • Transform text with sed and awk
  • Edit files in vim or nano
  • Read man pages and --help
  • man7: hier(7) filesystem layout
  • GNU Coreutils manual

• Users, Permissions and Packages

  Core

  Many server problems and security holes come down to wrong ownership, careless sudo or unpatched packages, so get these right early.

  • Users, groups and sudo
  • Read and set modes with chmod
  • Change ownership with chown
  • Install and update with apt or dnf
  • Disks and mounts, df and du
  • Environment variables and PATH
  • man7: chmod(1)
  • Debian Reference: package management

• Processes, Services and Logs

  Core

  Apps in production run as long-lived services, so you need to start, stop and restart them and read their logs without guessing.

  • Inspect processes with ps and top
  • Signals, kill and exit codes
  • Write a systemd service unit
  • Enable, start and check services
  • Read logs with journalctl
  • Schedule jobs with cron or timers
  • Spot CPU, memory and disk pressure
  • systemd docs: service units
  • man7: journalctl(1)

• SSH and Remote Access

  Core

  SSH is how you reach servers and many CI runners, and a weak SSH setup is one of the easiest ways in for attackers.

  • Generate and use key pairs
  • Client config in ~/.ssh/config
  • Disable root and password login
  • Copy files with scp and rsync
  • Port forwarding and tunnels
  • Jump hosts and bastions
  • OpenSSH manual: ssh
  • OpenSSH manual: sshd_config

• TCP/IP and DNS

  Core

  A lot of "the site is down" tickets turn out to be networking or DNS, so you need a clear model of addresses, ports and name lookups.

  • IP addresses, subnets and CIDR
  • Ports, TCP and UDP
  • Private vs public addresses, NAT
  • DNS records: A, AAAA, CNAME, TXT
  • TTLs and resolver caching
  • Debug with dig, ss, ip, curl
  • man7: ip(8)
  • man7: ss(8)

• HTTP and TLS

  Core

  Nearly every service you deploy speaks HTTP over TLS, and header or certificate mistakes are some of the most visible failures.

  • Methods, status codes and headers
  • Inspect requests with curl -v
  • HTTP/2 and HTTP/3 basics
  • The TLS handshake in outline
  • Certificates, chains and expiry
  • Automate certificates with Let's Encrypt
  • MDN: Overview of HTTP
  • Let's Encrypt: how it works

• Nginx, Load Balancers and Firewalls

  Core

  A reverse proxy and a firewall sit in front of almost every app, so this is where your networking knowledge meets real traffic.

  • Nginx server blocks and locations
  • Reverse proxy to an app port
  • TLS termination at the proxy
  • Upstream load balancing methods
  • Layer 4 vs layer 7 balancing
  • Host firewalls with ufw or nftables
  • Default deny, open only needed ports
  • nginx docs: proxy module
  • nginx docs: load balancing

Automate routine server tasks with Bash and Python, and collaborate on infrastructure code through Git and pull requests.

• Bash Scripting

  Core

  Bash glues servers, containers and pipelines together, and short, careful scripts save you hours of repeated typing.

  • Variables, quoting and expansion
  • Conditionals, loops and functions
  • Exit codes and set -euo pipefail
  • Arguments and getopts
  • Traps and cleanup on exit
  • Lint scripts with ShellCheck
  • GNU Bash manual

• Python for Automation

  Core

  Once a script needs APIs, JSON or real error handling, Python is the usual next step, and it is the language DevOps job posts ask for most.

  • Virtual environments and dependencies
  • Files, paths and JSON
  • Run commands with subprocess
  • Call REST APIs over HTTP
  • Build CLIs with argparse
  • Logging and clear error handling
  • Cloud SDKs such as boto3
  • Python docs: subprocess
  • Python docs: argparse

• YAML, JSON and Config Files

  Core

  Pipelines, Compose files, Kubernetes manifests and playbooks are all YAML or JSON, and one bad indent can break a deploy.

  • YAML maps, lists and scalars
  • YAML gotchas: indentation and types
  • Query and reshape JSON with jq
  • Config through environment variables
  • Validate files before committing
  • jq manual
  • YAML specification

• Git Fundamentals

  Core

  All infrastructure and pipeline code lives in Git, so you need to commit, branch and undo mistakes without fear.

  • Commits, staging and history
  • Branches, merge and rebase
  • Resolve merge conflicts
  • Ignore files, keep secrets out
  • Tags for releases
  • Recover lost work with reflog
  • Pro Git book

• Pull Requests and Trunk-Based Development

  Core

  Teams ship small changes often by merging short-lived branches into one main branch, with reviews and automated checks guarding every merge.

  • Short-lived branches off main
  • Small, reviewable pull requests
  • Give and receive code review
  • Branch protection and required checks
  • Semantic versioning for releases
  • Clear, descriptive commit messages
  • GitHub docs: pull requests
  • GitHub docs: protected branches

• Go for Tooling

  Optional

  Kubernetes, Terraform and most cloud native tools are written in Go, so reading and writing a little of it helps on platform-heavy teams.

  • Syntax, types and packages
  • Modules and dependencies
  • Explicit error handling
  • Build static single binaries
  • Write a small CLI tool
  • A Tour of Go
  • Go docs: get started

Package any app into a small, secure image and run a multi-service stack locally with one command.

• How Containers Work

  Core

  Containers are what pipelines build and clusters run, so knowing what they really are prevents a lot of confusion later.

  • Images vs containers
  • Layers and the build cache
  • Namespaces and cgroups in outline
  • Containers vs virtual machines
  • The OCI image standard
  • Run, stop and remove containers
  • Docker docs: overview

• Writing Good Dockerfiles

  Core

  The Dockerfile decides how big, how fast to build and how safe your image is, and reviewers judge your work on it.

  • FROM, RUN, COPY, CMD, ENTRYPOINT
  • Order layers for cache hits
  • Use a .dockerignore file
  • Multi-stage builds
  • Small base images
  • Run as a non-root user
  • Add a HEALTHCHECK
  • Docker docs: multi-stage builds
  • Docker docs: build best practices

• Running and Debugging Containers

  Core

  Most container problems show up at runtime in ports, volumes, environment or logs, so you need a routine for tracking them down.

  • Publish ports to the host
  • Volumes vs bind mounts
  • Pass config with env vars
  • Read logs and exec inside
  • User-defined networks
  • Restart policies and resource limits
  • Docker docs: volumes

• Docker Compose

  Core

  Compose describes an app, its database and its cache in one file, which makes local environments and simple deployments repeatable.

  • Services, networks and volumes
  • Health checks and depends_on
  • Env files and profiles
  • Override files per environment
  • Rebuild services and follow logs
  • Docker docs: Compose

• Registries and Tagging

  Core

  Images must be stored, versioned and pulled by exact version, or you cannot tell what is actually running in production.

  • Push and pull from registries
  • GHCR, ECR and Docker Hub
  • Tag with git SHA and version
  • Pin images by digest
  • Avoid relying on latest
  • Multi-arch builds with buildx
  • GitHub docs: container registry
  • Docker docs: multi-platform builds

• Image Security Scanning

  Recommended

  Base images ship with known vulnerabilities and many teams block deploys that fail a scan, so scanning is part of building an image.

  • Scan with Trivy or Grype
  • Read and triage CVE reports
  • Fix by updating base images
  • Minimal, distroless or hardened bases
  • Generate an SBOM per image
  • Fail builds on critical findings
  • Trivy docs
  • Docker Scout docs

• Podman and Rootless Containers

  Optional

  Some Linux-heavy and enterprise teams use Podman instead of Docker, and knowing it shows you understand containers beyond one tool.

  • Daemonless, rootless containers
  • Docker-compatible CLI
  • Pods in Podman
  • Run containers under systemd
  • Podman docs

Build a pipeline that tests, scans and ships every merged change to staging and production, with a safe way back.

• Pipeline Design

  Core

  A good pipeline gives fast, trustworthy feedback on every change, and it is the backbone of how a team ships.

  • Stages: lint, test, build, scan, deploy
  • Fail fast, run slow jobs later
  • Build once, promote the same artifact
  • Pipeline config lives in the repo
  • Keep main always deployable
  • Track pipeline duration and flaky tests
  • GitHub docs: understanding Actions

• GitHub Actions

  Core

  GitHub Actions is built into GitHub and widely used by companies and open source projects, which makes it a practical first CI system.

  • Workflows, jobs and steps
  • Triggers: push, pull_request, manual
  • Matrix builds
  • Reusable workflows and composite actions
  • Hosted vs self-hosted runners
  • Concurrency and cancelling stale runs
  • GitHub docs: workflow syntax
  • GitHub docs: reusable workflows

• Caching and Artifacts

  Core

  Caching keeps pipelines fast and artifacts pass exact build outputs between jobs, which matters once builds take more than a few minutes.

  • Cache dependencies by lockfile hash
  • Docker layer cache in CI
  • Upload and download artifacts
  • Publish test and coverage reports
  • Retention and storage costs
  • GitHub docs: dependency caching
  • Docker docs: cache in GitHub Actions

• Secrets, Environments and Permissions

  Core

  Pipelines hold the keys to production, which makes them a favorite target, so they need tight, short-lived credentials.

  • Repository and environment secrets
  • OIDC to the cloud, no stored keys
  • Environments with required approvals
  • Least-privilege GITHUB_TOKEN permissions
  • Pin third-party actions to a SHA
  • Never print secrets in logs
  • GitHub docs: OpenID Connect
  • GitHub docs: secure use reference

• Deployment Strategies

  Core

  How you roll out a release decides how many users see a bad version and how quickly you can undo it.

  • Rolling updates
  • Blue/green switches
  • Canary releases watched by metrics
  • Automated rollback triggers
  • Backward-compatible database migrations
  • Smoke tests after every deploy
  • Argo Rollouts docs: concepts

• Feature Flags

  Recommended

  Flags separate deploying code from releasing a feature, so teams can merge to main daily and switch things off without a redeploy.

  • Deploy vs release
  • Release, experiment and ops flags
  • Percentage and targeted rollouts
  • OpenFeature as a vendor-neutral API
  • Remove stale flags
  • OpenFeature docs: introduction

• GitLab CI

  Optional

  Many companies, especially self-hosted ones, run GitLab, and its pipeline model maps closely to what you learned with Actions.

  • .gitlab-ci.yml stages and jobs
  • Runners and executors
  • rules and needs keywords
  • Includes and templates
  • Protected variables and environments
  • GitLab docs: CI/CD

Design, build and secure a simple production setup on AWS by hand, and explain what each piece costs.

• IAM and Account Security

  Core

  Every AWS action is an IAM decision, and many cloud breaches start with an overly broad key or role.

  • Secure the root user with MFA
  • Users vs roles vs Identity Center
  • Read and write JSON policies
  • Assume roles for temporary access
  • Least privilege and Access Analyzer
  • CLI profiles and SSO login
  • AWS docs: IAM best practices

• VPC Networking

  Core

  A VPC is your private network in the cloud, and getting subnets and routing right is what keeps databases off the internet.

  • Plan CIDR ranges
  • Public vs private subnets
  • Route tables and internet gateways
  • NAT gateways and their cost
  • Security groups vs network ACLs
  • VPC endpoints for AWS services
  • AWS docs: what is Amazon VPC

• Compute: EC2, Containers and Serverless

  Core

  You need to know when a workload belongs on a VM, a managed container service or a function, because each has different costs and upkeep.

  • EC2 instance types and AMIs
  • User data for bootstrapping
  • Launch templates and Auto Scaling
  • ECS on Fargate for containers
  • Lambda for event-driven jobs
  • Session Manager instead of open SSH
  • AWS docs: Amazon EC2
  • AWS docs: Amazon ECS

• Storage and Databases

  Core

  State is the hardest part of any system, so you must know how AWS stores files and databases and how to back them up.

  • S3 buckets, classes and lifecycle
  • Block public access by default
  • EBS volumes and snapshots
  • RDS Multi-AZ and read replicas
  • Automated backups and restores
  • Encryption at rest with KMS
  • AWS docs: Amazon S3
  • AWS docs: Amazon RDS

• Load Balancing, DNS and Certificates

  Core

  This is how users actually reach your app on AWS, and it ties together what you learned about Nginx, DNS and TLS in stage one.

  • ALB vs NLB
  • Target groups and health checks
  • Route 53 records and routing
  • Free certificates with ACM
  • CloudFront for static assets
  • AWS docs: Application Load Balancers

• CloudWatch and CloudTrail

  Core

  Before adding third-party tools, you should be able to see metrics, logs and an audit trail using what AWS already gives you.

  • Metrics and alarms
  • Log groups and Logs Insights
  • CloudTrail for API auditing
  • Alarm notifications through SNS
  • Log retention settings
  • AWS docs: Amazon CloudWatch

• Cost Awareness and Other Clouds

  Recommended

  Teams expect DevOps engineers to spot waste early and to carry their AWS knowledge over to Azure or Google Cloud when a job needs it.

  • On-demand, spot and savings plans
  • Budgets and cost alerts
  • Tag resources for cost tracking
  • Data transfer and NAT charges
  • Map services to Azure and GCP
  • Tear down what you do not use
  • AWS docs: managing costs with Budgets
  • Google Cloud docs: service comparison

Rebuild a whole environment from code, review infrastructure changes in pull requests and configure servers repeatably.

• Terraform Basics

  Core

  Declaring infrastructure in code makes it reviewable and repeatable, and the Terraform language, shared with OpenTofu, is the IaC skill job posts ask for most.

  • Providers and resources
  • Variables, outputs and locals
  • Data sources
  • init, plan, apply, destroy
  • Read every plan before applying
  • Commit the dependency lock file
  • Terraform tutorials: get started on AWS
  • Terraform docs: language

• State and Backends

  Core

  State is how the tool knows what already exists, and losing or corrupting it is one of the worst IaC incidents you can have.

  • What state stores and why
  • Remote state in S3 with locking
  • Separate state per environment
  • Import existing resources
  • Refactor with moved blocks
  • Detect and fix drift
  • Treat state as sensitive data
  • Terraform docs: state
  • Terraform docs: S3 backend

• Modules and Project Layout

  Core

  Modules let you reuse a tested network or service pattern across environments instead of copying files around.

  • Module inputs and outputs
  • count vs for_each
  • Pin module and provider versions
  • One folder per environment
  • Use registry modules with care
  • Keep modules small and focused
  • Terraform docs: modules

• IaC in Pipelines

  Core

  Running plans on pull requests and applies from CI removes laptop drift and gives every infrastructure change a reviewer.

  • fmt, validate and lint
  • Plan on PR, post the output
  • Apply on merge only
  • OIDC credentials for the runner
  • Scan code with Checkov or Trivy
  • Policy checks before apply
  • Terraform tutorials: automate with GitHub Actions

• OpenTofu

  Recommended

  OpenTofu is the open source Terraform fork under the Linux Foundation, a growing number of teams pick it for new projects, and most existing Terraform code works with it.

  • Why the fork exists
  • The tofu CLI and registry
  • Client-side state encryption
  • Migrating from Terraform
  • Where the two tools differ
  • OpenTofu docs
  • OpenTofu docs: state encryption

• Configuration with Ansible

  Recommended

  Terraform creates servers and Ansible configures what runs on them, which is still common wherever VMs and on-prem machines exist.

  • Static and dynamic inventories
  • Playbooks, tasks and modules
  • Idempotent tasks and handlers
  • Roles and collections
  • Templates with Jinja2
  • Secrets with ansible-vault
  • Ansible docs: getting started
  • Ansible docs: playbook guide

• Other IaC Tools

  Optional

  Some teams use cloud-native or general-purpose-language IaC instead, and recognizing these tools makes you easier to hire.

  • CloudFormation templates and stacks
  • AWS CDK in TypeScript or Python
  • Pulumi with general-purpose languages
  • Crossplane for Kubernetes-managed infrastructure
  • AWS CDK developer guide
  • Pulumi docs

Deploy, expose, scale and debug services on a Kubernetes cluster, and let Git drive every change to it.

• Cluster Basics and Workloads

  Core

  Kubernetes is the default platform for running containers at scale, and everything starts with the objects that keep your pods running.

  • Control plane and worker nodes
  • kubectl, contexts and namespaces
  • Pods, Deployments and ReplicaSets
  • StatefulSets, DaemonSets and Jobs
  • Labels and selectors
  • Debug with describe, logs, events
  • Practice locally with kind
  • Kubernetes docs: cluster components
  • Kubernetes docs: Deployments

• Services, Gateway API and Network Policy

  Core

  Pods come and go, so you need stable ways to reach them, and since the community ingress-nginx controller was retired in 2026, new setups should use the Gateway API.

  • Service types: ClusterIP, NodePort, LoadBalancer
  • Cluster DNS names
  • Gateways and HTTPRoutes
  • Ingress in existing clusters
  • Migrating off ingress-nginx
  • NetworkPolicies with default deny
  • Kubernetes docs: Services
  • Kubernetes docs: Gateway API

• Configuration, Secrets and Storage

  Core

  Keeping config out of images and data on durable volumes is what lets the same image run safely in every environment.

  • ConfigMaps as env or files
  • Secrets are encoded, not encrypted
  • Encrypt secrets at rest
  • PersistentVolumes and claims
  • StorageClasses and dynamic provisioning
  • Kubernetes docs: Secrets
  • Kubernetes docs: persistent volumes

• Resources, Probes and Autoscaling

  Core

  Missing requests, limits and probes are behind many common Kubernetes incidents, from evicted pods to traffic hitting apps that are not ready.

  • Requests vs limits
  • QoS classes and OOM kills
  • Liveness, readiness and startup probes
  • Horizontal Pod Autoscaler
  • PodDisruptionBudgets
  • Node autoscaling, for example Karpenter
  • Kubernetes docs: resource management
  • Kubernetes docs: configure probes

• Helm and Kustomize

  Core

  Raw YAML does not scale across many services and environments, so teams package apps as Helm charts or patch them with Kustomize.

  • Chart structure and templates
  • Values files per environment
  • Install, upgrade and roll back
  • Charts from OCI registries
  • Kustomize bases and overlays
  • Render and diff before applying
  • Helm docs: using Helm
  • Kubernetes docs: Kustomize

• Managed Kubernetes: EKS, GKE, AKS

  Recommended

  Most companies rent the control plane from a cloud provider, so you need to know what the provider manages and what is still your job.

  • What the provider manages
  • Managed node groups and Fargate
  • Pod-level IAM with Pod Identity
  • Load balancer controller integration
  • Plan cluster version upgrades
  • Provision clusters with Terraform
  • AWS docs: what is Amazon EKS

• GitOps with Argo CD or Flux

  Core

  With GitOps the cluster pulls its desired state from Git, which gives you history, easy rollback and no kubectl from laptops, and Argo CD is the most widely adopted tool for it.

  • Declarative, versioned, pulled, reconciled
  • Argo CD Applications and projects
  • Sync, self-heal and pruning
  • ApplicationSets for many clusters
  • Promote images across environments
  • Flux as the main alternative
  • Argo CD docs
  • Flux docs

Notice when a service is unhealthy before users do, find out why, and recover data and service after a failure.

• Metrics with Prometheus

  Core

  Metrics are the cheapest way to see trends and trigger alerts, and Prometheus is the standard choice in Kubernetes environments.

  • Counters, gauges and histograms
  • Scrape targets and service discovery
  • Exporters such as node_exporter
  • PromQL: rate, sum, by
  • Recording rules
  • Keep label cardinality low
  • Prometheus docs: overview
  • Prometheus docs: querying basics

• Dashboards with Grafana

  Core

  Good dashboards answer "is it broken, and where" in seconds, which is exactly what you need during an incident.

  • Connect data sources
  • RED method for services
  • USE method for resources
  • Variables for reusable dashboards
  • Dashboards as code in Git
  • Grafana docs: fundamentals
  • Grafana docs: dashboards

• Logs and Log Pipelines

  Core

  Logs explain what happened in detail, but only if they are structured, collected in one place and kept at a cost you can afford.

  • Structured JSON logs
  • Log levels and what to log
  • Ship logs with Fluent Bit
  • Store in Loki or OpenSearch
  • Retention and cost limits
  • Correlate logs with trace IDs
  • Grafana Loki docs
  • Fluent Bit manual

• Tracing with OpenTelemetry

  Core

  In systems with many services, traces show where time and errors come from, and OpenTelemetry is now the vendor-neutral standard for traces, metrics and logs.

  • Traces, spans and attributes
  • Context propagation between services
  • Auto vs manual instrumentation
  • The OpenTelemetry Collector
  • Export with OTLP
  • Backends such as Jaeger or Tempo
  • Sampling to control cost
  • OpenTelemetry docs: concepts
  • OpenTelemetry docs: Collector

• SLIs, SLOs and Alerting

  Core

  Alerting on user-facing symptoms against an agreed target keeps on-call bearable and tells the team when to slow down and fix reliability.

  • Choose SLIs users care about
  • Set SLOs and error budgets
  • Alert on symptoms, not causes
  • Burn-rate alerts
  • Route alerts with Alertmanager
  • Every alert needs a runbook
  • Google SRE book: service level objectives
  • Google SRE workbook: alerting on SLOs

• Incident Response and Postmortems

  Core

  Every team has outages, and what earns trust is handling them calmly and making sure the same one does not happen twice.

  • Severity levels and escalation
  • Incident commander and other roles
  • Status updates to stakeholders
  • Mitigate first, find root cause later
  • Blameless postmortems
  • Track action items to done
  • Google SRE book: managing incidents
  • Google SRE book: postmortem culture

• Backups and Disaster Recovery

  Core

  A backup you have never restored is only a hope, and recovery targets decide how much data and time the business can afford to lose.

  • RPO and RTO targets
  • The 3-2-1 backup rule
  • Automate and test restores
  • Back up clusters with Velero
  • Multi-AZ vs multi-region
  • Game days and recovery drills
  • AWS whitepaper: disaster recovery on AWS
  • Velero docs