EXIN DevOps Foundation flashcards
EXIN DevOps Foundation · Build recall with a focused review session.
32 cards. Read the term and the definition here. The deck at the top of this page is optional.
- DevOps definition
- A cultural and organizational movement that unites development and operations around shared goals, shared tooling, and shared responsibility for delivering value to customers continuously.
- The Three Ways
- Gene Kim's principles: flow and systems thinking from Dev to Ops to customer, amplified feedback loops, and a culture of continual experimentation and learning.
- CALMS model
- An assessment framework for DevOps maturity: Culture, Automation, Lean, Measurement, and Sharing. It is used as a checklist, not as a prescriptive standard.
- DORA metrics
- Four delivery performance measures: lead time for changes, deployment frequency, mean time to restore, and change failure rate. They are read together, not individually.
- DevOps versus Agile
- Agile focuses on planning, collaboration, and development cadence; DevOps extends the same Lean thinking through deployment, operations, and production feedback.
- Silo problem
- Dev and Ops having conflicting incentives: developers rewarded for change, operations rewarded for stability. This tension drives handoffs, blame, and slow releases.
- DevOps is not a role
- DevOps describes a way of working and a set of practices. Naming a team 'the DevOps team' without changing incentives or responsibility does not create DevOps.
- First Way: flow
- Optimize the whole value stream from request to customer. Make work visible, limit work in progress, reduce batch size, and never pass defects downstream.
- Second Way: feedback
- Shorten and amplify feedback loops so defects and problems are detected close to their source and corrected quickly, rather than discovered late in production.
- Third Way: learning
- Institutionalize experimentation and improvement. Failure is treated as information, and blameless retrospectives convert incidents into lasting process changes.
- Shift left
- Move testing, quality, and security activities earlier in the lifecycle. Defects detected during design or coding cost far less to fix than production defects.
- Shift right
- Extend testing, monitoring, and resilience practices into production, because real user behavior and real load are the ultimate validation of a system.
- You build it, you run it
- The team that writes a service is also accountable for operating it. This closes the feedback loop and removes the throw-it-over-the-wall handoff to operations.
- Systems thinking
- Judging improvements by their effect on the whole value stream. Maximizing one team's utilization typically reduces overall throughput and increases queue time.
- Blameless culture
- Post-incident reviews examine systemic causes and process weaknesses rather than punishing individuals, so people report problems honestly instead of hiding them.
- Small batch size
- Delivering changes in small increments shortens lead time, reduces risk per release, and simplifies diagnosis when something goes wrong in production.
- Continuous Integration
- Developers merge changes to a shared mainline frequently, and each merge triggers an automated build and automated tests to detect integration problems early.
- Continuous Delivery
- Every change is kept in a deployable state and can be released to production on demand. Release is a business decision, not a technical constraint.
- Continuous Deployment
- An extension of continuous delivery in which every change that passes automated pipeline checks is released to production automatically, without a manual approval step.
- Infrastructure as Code
- Environments and infrastructure are defined in version-controlled, reviewable files and applied automatically, making provisioning repeatable and reducing configuration drift.
- Immutable infrastructure
- Servers or containers are replaced rather than modified in place. This eliminates configuration drift and makes environments reproducible and predictable.
- Trunk-based development
- Developers integrate into a shared mainline at least daily using short-lived branches. This reduces merge conflicts and keeps the codebase continuously integrable.
- Testing pyramid
- A test portfolio shaped like a pyramid: many fast unit tests, fewer service or API tests, and very few slow end-to-end UI tests that are brittle.
- CI/CD pipeline
- An automated sequence such as build, test, static analysis, package, deploy to test, acceptance test, deploy to production, and verification, triggered by each change.
- Observability
- The ability to understand a system's internal state from its outputs, typically metrics, logs, and distributed traces, supporting fast diagnosis of production issues.
- DevSecOps
- Security activities such as dependency scanning, secrets management, and policy as code are automated inside the delivery pipeline rather than performed as a late manual gate.
- Value stream mapping
- A technique that charts the steps and wait times from a customer request to delivered value, exposing handoffs and the largest bottleneck to improve first.
- Pilot selection rule
- Choose a small cross-functional team and a meaningful but non-critical service as the first DevOps pilot, then expand after measurable results are demonstrated.
- Outcome metrics first
- Define delivery and customer outcome measures before changing tooling, so improvement can be proven and tool choices are justified by evidence rather than fashion.
- Automate the pain first
- Automate the most frequent and most painful manual step, often environment provisioning or deployment, rather than the most technically interesting component.
- Adoption barriers
- Typical obstacles include conflicting reward structures, blame after incidents, legacy architecture, and compliance rules interpreted as forbidding frequent change.
- Auditability without gatekeeping
- Frequent change can stay auditable through pipeline logs, peer-reviewed infrastructure code, and automated policy checks instead of manual approval boards.