EXIN DevOps Professional study materials
EXIN DevOps Professional study resources

EXIN DevOps Professional cheat sheet

EXIN DevOps Professional · Keep the key ideas within reach.

Quick reference

DevOps Practices: Flow, Feedback, Continual Learning

  • Three Ways: Flow (left-to-right fast delivery), Feedback (right-to-left amplification), Continual Learning (experiment and repetition).

  • Flow metrics: lead time = commit to production; cycle time = work start to done; WIP is work in progress between defined stages.

  • Little's Law: average lead time = average WIP / average throughput; cut WIP or raise throughput to shorten lead time.

  • Batch size rule: smaller batches reduce queue time and variability; deploy work is sized to fit within one deployment window.

  • Deployment pipeline stages: version control, build, unit test, acceptance test, performance test, deploy. Each stage gates the next.

  • Feedback rule: the further downstream a defect is found, the higher the cost; shift detection left to the earliest possible stage.

  • Andon principle: any team member can stop the line when a defect is detected; the stop is a signal to swarm and fix, not to blame.

  • Blameless postmortem outputs: timeline, contributing factors, and countermeasures with owners; no individual punishment for honest error.

  • Improvement cadence: kaizen (continuous small improvement) plus kaikaku (radical change); reserve capacity for improvement work.

Quick reference

DevOps Culture and Organizational Change

  • Westrum typology: pathological (power-oriented, blame), bureaucratic (rule-oriented, silos), generative (performance-oriented, information shared openly).

  • Generative culture predicts higher software delivery performance; culture is measured by how information flows, not by stated values.

  • Blameless culture definition: people are not punished for errors, but accountability for countermeasures remains.

  • Autonomy rule: teams own their services end to end, including build, run, and on-call; handoff to a separate ops team is an anti-pattern.

  • Conway's Law: system architecture mirrors organizational communication structure; restructure teams to get the architecture you want.

  • Change management: Kotter-style urgency plus coalition; transformation fails when leadership does not model the new behavior.

  • Psychological safety: team members can raise risks and admit mistakes without retaliation; it is a precondition for fast feedback.

  • Team topology: stream-aligned, enabling, complicated-subsystem, and platform teams; platform teams offer services as products, not mandates.

  • Diversity and inclusion correlate with better team outcomes; hiring and retention practices are part of DevOps culture, not HR trivia.

Quick reference

DevOps Automation and Tooling

  • Infrastructure as Code: environments are defined in versioned files and recreated, never hand-configured; the repository is the source of truth.

  • Idempotency rule: applying the same configuration twice yields the same state; non-idempotent scripts are a defect.

  • Immutable infrastructure: servers are replaced, not patched in place; enables identical rebuilds and rollback by redeploy.

  • CI rule: every commit triggers build plus automated tests; a broken mainline is fixed or reverted before new work merges.

  • Trunk-based development: short-lived branches merged at least daily; long-lived feature branches increase merge risk.

  • Deployment vs release: deployment puts code on servers; release exposes it to users via feature flags. Decoupling enables dark launches.

  • Blue-green deployment: two identical environments; switch traffic after the new one passes checks; instant rollback by switching back.

  • Canary release: route a small percentage of traffic to the new version, compare error and latency metrics, then expand or roll back.

  • Secret management: credentials live in a vault or secret store injected at runtime, never in source control or build logs.

Quick reference

DevOps Measurement, Metrics and Resilience

  • DORA four keys: deployment frequency, lead time for changes, change failure rate, time to restore service.

  • Deployment frequency and lead time measure throughput; change failure rate and time to restore measure stability. Both are needed.

  • Elite performance reference: on-demand deployment (multiple per day), lead time under one hour, change failure rate 0-15%, restore under one hour.

  • Metric anti-pattern: using individual velocity or lines of code as a performance target produces gaming; measure outcomes, not activity.

  • Error budget: 100% minus SLO target; for a 99.9% SLO the budget is 0.1% of time. Exhausting it freezes feature work until reliability returns.

  • SLI is the measured indicator; SLO is the target for that indicator; SLA is a contractual commitment with consequences.

  • Four golden signals: latency, traffic, errors, saturation. Alert on symptoms users feel, not on every internal cause.

  • MTTR (mean time to restore) is a resilience measure; reduce it with fast detection, automated rollback, and rehearsed incident response.

  • Chaos engineering: deliberately inject faults in a controlled experiment to verify resilience; requires a hypothesis and a stop condition.