GISI ADO Level study materials
GISI ADO Level study resources

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.