EXIN DevOps Master flashcards
EXIN DevOps Master · 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.
- Three Ways
- The core principles of DevOps: flow, feedback, and continual learning. Flow optimizes delivery from development to operations; feedback amplifies learning; continual learning fosters experimentation and improvement.
- CALMS
- A framework for assessing DevOps adoption: Culture, Automation, Lean, Measurement, Sharing. It emphasizes that tools alone are insufficient without cultural change and measurement.
- Deployment frequency
- A key DevOps metric measuring how often an organization successfully releases to production. High performers deploy on demand, multiple times per day.
- Lead time for changes
- The time from code commit to code running in production. It is a key metric for DevOps performance, indicating the efficiency of the delivery pipeline.
- Change failure rate
- The percentage of changes to production that result in degraded service and require remediation. It is one of the four key DevOps metrics from DORA research.
- Mean time to restore
- The average time to recover from a failure in production. Also called MTTR. It is a key DevOps metric reflecting resilience and incident response effectiveness.
- Blameless postmortem
- A structured review after an incident focusing on systemic causes rather than individual blame. It encourages transparency and learning, and produces actionable improvements.
- Value stream mapping
- A Lean technique to visualize the flow of work from concept to customer, identifying waste and bottlenecks. Used in DevOps adoption to optimize delivery processes.
- Shift-left
- The practice of integrating testing, security, and operations concerns early in the software development lifecycle, rather than after deployment, to reduce defects and costs.
- Definition of Done
- A shared understanding of what it means for a product increment to be complete. In DevOps, it includes operational criteria like automated tests, security scans, and monitoring.
- Non-functional requirements
- Requirements describing system qualities such as performance, security, scalability, and reliability. They must be captured as user stories with acceptance criteria and validated continuously.
- Infrastructure as Code
- Managing and provisioning infrastructure through machine-readable definition files, versioned and treated like application code. It enables repeatable, idempotent, and auditable environments.
- Twelve-Factor App
- A methodology for building cloud-native applications, emphasizing codebase, dependencies, config, backing services, build/release/run, processes, port binding, concurrency, disposability, dev/prod parity, logs, and admin processes.
- Microservices
- An architectural style structuring an application as a collection of loosely coupled, independently deployable services organized around business capabilities, with decentralized data management and API contracts.
- Pipeline as code
- Defining the continuous delivery pipeline in a versioned configuration file stored with the application code, enabling review, reuse, and consistency across environments.
- Blue-green deployment
- A release technique using two identical environments: blue (current) and green (new). Traffic is switched to green after validation, enabling zero-downtime deployment and quick rollback.
- Canary release
- A deployment pattern that routes a small percentage of production traffic to a new version, monitoring for issues before gradually rolling it out to all users.
- Trunk-based development
- A version control practice where developers commit to a single shared branch (trunk) frequently, using short-lived feature branches and feature flags to avoid long-lived divergence.
- Continuous Integration
- A practice where developers merge code changes into a shared repository frequently, triggering automated builds and tests to detect integration issues early.
- Continuous Delivery
- A software engineering approach where code changes are automatically built, tested, and prepared for release to production, ensuring the software is always in a deployable state.
- Continuous Deployment
- An extension of continuous delivery where every change that passes automated tests is automatically deployed to production without manual intervention.
- Test automation pyramid
- A testing strategy with many fast unit tests at the base, fewer service/API tests in the middle, and few slow UI/end-to-end tests at the top, optimizing speed and coverage.
- Feature toggle
- A technique allowing code to be deployed without releasing a feature to users. It enables trunk-based development and controlled rollout by turning features on or off at runtime.
- DevSecOps
- The integration of security practices into DevOps processes, including static and dynamic analysis, dependency scanning, and secrets management, embedded throughout the CI/CD pipeline.
- Observability
- The ability to understand a system's internal state from its external outputs, typically through logs, metrics, and traces. It enables proactive monitoring and faster incident resolution.
- Service Level Indicator
- A quantitative measure of a service's performance, such as latency or error rate. SLIs are the basis for defining Service Level Objectives (SLOs).
- Service Level Objective
- A target value or range for a Service Level Indicator (SLI), such as 99.9% availability. SLOs guide reliability engineering and error budget management.
- Error budget
- The acceptable amount of unreliability derived from the SLO (1 - SLO). It balances innovation and stability; when exhausted, reliability work takes priority over new features.
- Incident management
- The process of responding to and resolving production incidents, including severity classification, on-call rotations, runbooks, communication, and blameless postmortems.
- Auto-scaling
- The automatic adjustment of computational resources based on load, using metrics-based triggers and scaling policies. It supports elasticity and cost efficiency in cloud environments.
- Chaos engineering
- The practice of deliberately introducing failures into a system to test its resilience and validate that it can withstand turbulent conditions in production.
- Immutable infrastructure
- A paradigm where servers are never modified after deployment; instead, they are replaced with new versions. This reduces configuration drift and improves consistency and reliability.