EXIN DevOps Professional flashcards
EXIN DevOps Professional · 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 of DevOps
- Flow accelerates delivery from development to operations; feedback shortens the loop from operations back to development; continual learning builds a culture of experimentation and repetition.
- Lead time for changes
- Elapsed time from code commit to that change running in production. It is a flow metric and one of the DORA four keys, capturing the whole delivery pipeline.
- Little's Law
- Average lead time equals average work in progress divided by average throughput. Reducing WIP or increasing throughput shortens the time items spend in the system.
- Deployment pipeline
- An automated sequence of stages, such as build, unit test, acceptance test and deploy, that gives fast feedback on every change and gates progression to production.
- Andon cord
- A practice where any team member can stop the production line on detecting a problem, triggering immediate swarm and fix rather than passing the defect downstream.
- Blameless postmortem
- A structured review after an incident that documents timeline and contributing factors and assigns countermeasures, without punishing individuals for honest mistakes.
- Shift left
- Moving testing, security and quality checks earlier in the delivery pipeline so defects are found when they are cheapest to fix.
- Kaizen and kaikaku
- Kaizen is continuous incremental improvement by the team; kaikaku is radical, large-scale change. DevOps improvement programs need both modes.
- Westrum organizational typology
- Three culture types: pathological, power-oriented and blame-focused; bureaucratic, rule-oriented with silos; generative, performance-oriented where information flows openly. Generative predicts better delivery performance.
- Generative culture
- A culture type where information is shared openly, cooperation is high, novelty is accepted, and messengers of bad news are not punished.
- Conway's Law
- The observation that system architecture tends to mirror the communication structure of the organization that builds it, so team design shapes the software you get.
- Psychological safety
- A team climate where members can admit mistakes, ask questions and raise risks without fear of retaliation, enabling fast feedback and learning.
- Stream-aligned team
- A team aligned to a single value stream or product, owning it end to end including build, run and on-call, minimizing handoffs to other teams.
- Platform team
- A team that provides internal services and tooling as a product to stream-aligned teams, reducing their cognitive load without imposing mandatory process.
- Blameless accountability
- People are not punished for errors, but the organization still tracks countermeasures and owners so the same failure mode is not repeated.
- Change coalition
- A group of influential leaders who visibly sponsor a transformation, model the new behaviors and remove obstacles, giving organizational change credibility.
- Infrastructure as Code
- Defining servers, networks and configuration in version-controlled files so environments are reproducible, reviewable and recreated rather than hand-configured.
- Idempotency
- A property of automation where applying the same configuration or script repeatedly produces the same end state, making reruns safe after partial failure.
- Immutable infrastructure
- Servers and containers are replaced rather than modified in place. Rebuilds are identical, configuration drift disappears and rollback means redeploying a prior image.
- Trunk-based development
- Developers merge small changes to a shared mainline at least daily, using short-lived branches and feature flags to hide incomplete work.
- Deployment versus release
- Deployment places code on servers; release exposes it to users. Feature flags separate the two so code can ship dark and be enabled later.
- Blue-green deployment
- Two identical environments, one live and one idle. The new version deploys to the idle one, traffic switches after checks, and rollback is another switch.
- Canary release
- A small slice of traffic is routed to the new version while error and latency metrics are compared with the baseline, expanding or rolling back based on evidence.
- Continuous integration
- Every commit triggers an automated build and test run, and a failing mainline is fixed or reverted before new work merges, keeping the codebase releasable.
- Secret management
- Credentials, tokens and keys are stored in a vault or secret store and injected at runtime, never committed to source control or printed in build logs.
- DORA four keys
- Deployment frequency, lead time for changes, change failure rate and time to restore service. The first two measure throughput, the last two stability.
- Change failure rate
- The percentage of deployments to production that cause degraded service and require remediation such as a hotfix or rollback. It is a stability metric.
- Error budget
- One hundred percent minus the service level objective. For a 99.9 percent SLO the budget is 0.1 percent of time; exhausting it pauses feature work until reliability recovers.
- SLI, SLO and SLA
- The SLI is the measured indicator, the SLO is the internal target for it, and the SLA is a contractual commitment with defined consequences for missing it.
- Four golden signals
- Latency, traffic, errors and saturation. Monitoring these four gives a compact view of service health and supports alerting on symptoms users experience.
- Chaos engineering
- Deliberately injecting controlled faults into a system to test resilience, guided by a hypothesis and a stop condition, usually run first in non-production.
- Metric gaming
- When a measure becomes a target, people optimize the number rather than the outcome. Individual velocity or lines-of-code targets are classic examples to avoid.