GISI ADO Level flashcards
GISI ADO Level · 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 CALMS framework
- An assessment model naming five pillars: Culture, Automation, Lean flow, Measurement, and Sharing. It is used to evaluate organizational DevOps maturity beyond tooling alone.
- DORA four key metrics
- Deployment frequency, lead time for changes, change failure rate, and time to restore service. Throughput metrics pair with stability metrics; elite performers score well on both simultaneously.
- Change failure rate formula
- Failed deployments divided by total deployments in the same period. A deployment counts as failed if it causes degraded service requiring a hotfix, rollback, or emergency patch.
- The Three Ways
- Flow (optimize left-to-right delivery), feedback (amplify fast loops from right to left), and continual learning (experiment and share knowledge). They form the conceptual foundation of DevOps improvement.
- Git commit object contents
- A commit stores a pointer to a tree snapshot, zero or more parent commits, author and committer identity with timestamps, and the commit message. Its SHA-1 or SHA-256 identifies it uniquely.
- Merge versus rebase
- Merge joins two histories with a merge commit and preserves original SHAs. Rebase replays commits onto a new base, creating new SHAs and linear history, so it must not be used on shared branches.
- git reset modes
- Soft moves HEAD only, leaving index and working tree intact. Mixed also resets the index. Hard additionally overwrites the working tree, discarding uncommitted changes permanently.
- Fast-forward merge condition
- A fast-forward occurs only when the current branch tip is an ancestor of the branch being merged, so no new merge commit is needed and the pointer simply advances.
- Annotated versus lightweight tags
- Lightweight tags are bare refs pointing at a commit. Annotated tags are full objects storing tagger identity, date, and message, making them suitable for signed release markers.
- Continuous integration definition
- Every developer integrates into a shared mainline at least daily, and each integration triggers an automated build and test run on a clean environment, giving fast feedback on breakage.
- Build once, promote artifact
- The pipeline compiles and packages exactly one immutable artifact, then promotes that same artifact through staging to production. Rebuilding per environment invalidates prior test evidence.
- Test pyramid ordering
- Many fast unit tests at the base, fewer service and contract tests in the middle, and few slow end-to-end tests at the top. Inverting it produces slow, brittle pipelines.
- Flaky test handling
- A flaky test passes and fails nondeterministically on unchanged code. Quarantine it from the blocking gate, track its flake rate, and fix root causes rather than silently retrying.
- Branch protection required checks
- Rules on the main branch typically require passing status checks, at least one approving review, and no direct pushes, ensuring the mainline stays green and reviewed.
- Delivery versus deployment
- Continuous delivery keeps the mainline always releasable but leaves production release as a business decision. Continuous deployment automatically ships every change that passes all gates.
- Blue-green deployment
- Two identical environments run in parallel; traffic switches from blue to green after verification. Rollback is a traffic switch back, but both versions must remain schema-compatible.
- Canary release
- A small percentage of traffic is routed to the new version, and the share expands only if health metrics stay within thresholds. It limits blast radius but needs per-version observability.
- Expand-contract schema migration
- Add the new schema alongside the old, dual-write and backfill, switch reads to the new structure, then remove the old. This keeps mixed application versions working during rollout.
- Feature flag decoupling
- Flags separate deployment from release, allowing dark launches, percentage rollouts, and instant kill switches without redeploying. Stale flags accumulate as technical debt and must be removed.
- Terraform plan and apply
- Plan compares declared configuration against state and real resources to preview the diff. Apply executes the changes. Remote state with locking prevents concurrent applies from corrupting the mapping.
- Idempotency in infrastructure code
- Applying the same configuration repeatedly produces the same end state with no further changes. Non-idempotent scripts create duplicates, so repeated 'changed' reports signal a defect.
- Configuration drift
- Divergence between declared infrastructure state and actual running resources, usually caused by manual console edits. Drift is detected by plan or compliance scans and corrected by re-apply.
- Immutable infrastructure principle
- Servers and containers are replaced rather than patched in place. Baked images make rollback a matter of launching the previous image and eliminate configuration drift on long-lived hosts.
- Terraform state secrecy
- State files record resource attributes, including secrets such as passwords and keys, in plaintext. Store them in an encrypted, access-controlled backend with locking, never in version control.
- Ansible inventory and playbook
- An inventory lists managed hosts grouped by role. A playbook maps plays to host groups and runs idempotent modules; handlers notified by tasks run once at the end of the play.
- Configuration convergence
- A configuration management run compares actual host state to the desired state and changes only deviating resources. Repeated runs should report no changes once the host has converged.
- Automation blast-radius control
- Limiting how many hosts a change touches at once, using serial batches, canary hosts, and check mode, so a faulty configuration affects a small subset before fleet-wide rollout.
- Four golden signals
- Latency, traffic, errors, and saturation. They form the minimal monitoring set for a user-facing service, with latency split between successful and failed requests.
- SLI, SLO, and error budget
- An SLI is a measured indicator such as success rate; an SLO is its target, for example 99.9 percent. The error budget equals one minus the SLO and is consumed by failures.
- Tail latency percentiles
- p95 and p99 expose slow outlier requests that averages hide. Percentiles cannot be averaged across instances; aggregate raw histograms or sketch data instead.
- Shift-left security controls
- SAST, dependency and secret scanning, IaC scanning, and image scanning run inside the pipeline before merge or deploy, catching flaws when fixes are cheapest.
- OIDC federation for pipelines
- The CI system exchanges a short-lived identity token for scoped cloud credentials instead of storing long-lived static keys, reducing exposure if the pipeline is compromised.