GISI ADO Level cheat sheet

DevOps is a sociotechnical practice: it couples cultural norms (shared ownership, blameless learning) with tooling to shorten the lead time from commit to production.

CALMS framework names five pillars: Culture, Automation, Lean, Measurement, Sharing - used as a checklist for assessing DevOps maturity.

DORA four key metrics: deployment frequency, lead time for changes, change failure rate, and time to restore service (MTTR). Higher throughput metrics pair with lower stability metrics in high performers.

Lead time for changes is measured from commit to running in production, not from ticket creation; mean lead time is the arithmetic mean over merged changes in a period.

Change failure rate = failed deployments ÷ total deployments over the window; a deployment that requires hotfix or rollback counts as failed.

The Three Ways: (1) flow/left-to-right, (2) fast feedback loops, (3) continual experimentation and learning - the conceptual basis of value stream improvement.

Dev vs Ops incentives differ: dev optimizes for change, ops for stability; DevOps resolves this by shifting quality left and making deployments small, reversible, and observable.

Value stream mapping exposes wait states; typical finding is that actual work time is a small fraction of total lead time, so reducing queues beats speeding up tasks.

CI/CD pipelines are the automation boundary of DevOps: pipeline definitions are versioned code and are reviewed like application code.

Git stores snapshots, not deltas: each commit points to a tree of blobs; unchanged files are shared by reference, so commits are cheap.

Three areas: working tree, staging index (.git/index), and repository (.git/objects). git add stages; git commit writes a commit object referencing a tree and parent commit(s).

A branch is a movable pointer to a commit; HEAD points to the current branch (or is detached when pointing directly to a commit).

Merge vs rebase: merge preserves history and creates a merge commit; rebase rewrites commits onto a new base, producing linear history but new SHAs - never rebase shared branches.

Fast-forward merge occurs only when the target branch is a strict ancestor of the source; otherwise a three-way merge (or rebase) is required.

git reset --soft moves HEAD only; --mixed (default) also resets the index; --hard also resets the working tree and discards uncommitted changes.

git revert creates a new commit that inverses a prior commit - the safe undo for pushed history; git reset --hard rewrites history and breaks collaborators.

Tags: lightweight tags are plain refs; annotated tags are full objects with tagger, date, and message - releases should use annotated or signed tags.

Conflict markers <<<<<<< ======= >>>>>>> appear only in files Git cannot auto-merge; resolution requires staging the file and completing the merge commit.

CI definition: every developer integrates to a shared mainline at least daily, and each integration triggers an automated build plus test run on a clean environment.

A build is 'green' only if compile, unit tests, and static checks pass; a red mainline is a stop-the-line event - fixing it takes priority over new work.

Pipeline stage order by cost: lint/static analysis → unit tests → build artifact → integration tests → publish. Fail fast on the cheapest signal first.

Artifacts must be built once and promoted; rebuilding per environment breaks the guarantee that the tested binary is the deployed binary.

Test pyramid: many unit tests, fewer service/contract tests, few end-to-end UI tests; inverted pyramids (test ice cream cone) produce slow, flaky pipelines.

Flaky tests are non-deterministic passes/failures; quarantine them from the blocking gate and track a flake rate rather than retrying silently.

Build caching and parallelism reduce feedback time; cache keys must include lockfile hashes, otherwise stale dependencies cause false green builds.

Trunk-based development with short-lived branches (<1 day) minimizes merge conflicts; long-lived feature branches postpone integration risk.

Branch protection rules on main typically require: passing required status checks, at least one review approval, and no direct pushes.

Continuous delivery keeps mainline always releasable; deployment to production is a business decision. Continuous deployment removes that decision - every passing change ships automatically.

Deployment pipeline stages: commit → build → automated acceptance → staging → production; each stage is a quality gate that can reject the artifact.

Blue-green deployment runs two identical environments and switches traffic; rollback is a traffic switch back, but both environments must stay schema-compatible.

Canary release routes a small traffic percentage to the new version and expands on healthy metrics; it limits blast radius but requires per-version observability.

Rolling deployment replaces instances in batches; requires backward-compatible APIs and database migrations that work across mixed versions.

Feature flags decouple deploy from release; dark launching and percentage rollouts use flags, and stale flags are technical debt to be removed.

Expand-contract (parallel change) pattern for schema changes: add new column/table, dual-write/backfill, switch reads, then remove old - never break running versions.

Rollback vs roll-forward: rollback restores the prior artifact; roll-forward ships a fix. Database migrations often make rollback unsafe, favoring roll-forward.

Deployment frequency and time to restore are the delivery metrics most directly improved by small batch size and automated rollback.

IaC treats infrastructure definitions as versioned source; the same code produces dev, staging, and production, with differences expressed as parameters, not forks.

Declarative vs imperative: declarative tools (Terraform, CloudFormation) describe desired end state and compute the diff; imperative scripts (shell, Ansible ad-hoc) describe steps.

Terraform workflow: init (providers/modules) → plan (diff preview) → apply. State file maps real resources to code; remote state with locking prevents concurrent-apply corruption.

Terraform state contains secrets in plaintext - store it in an encrypted, access-controlled backend, never in Git.

Idempotency: applying the same configuration twice yields the same result with no changes; non-idempotent scripts create duplicates or drift.

Configuration drift is divergence between declared and actual state; detected by plan/drift detection and corrected by re-apply, not manual console edits.

Immutable infrastructure replaces servers rather than patching them; baked images (AMI/container) make rollback a matter of launching the previous image.

Modules and stacks: modules package reusable resource groups; remote modules must be version-pinned (semver or commit SHA) for reproducible builds.

Secrets in IaC: reference a secret manager at apply time (e.g., data sources) instead of committing values; scanning tools flag hardcoded credentials.

Configuration management enforces a desired state on hosts: packages, files, services, users. Convergence means repeated runs only fix what deviates.

Puppet/Chef use a declarative resource model with a catalog/run list; Ansible is agentless over SSH with idempotent modules and playbooks; Salt uses a master-minion event bus.

Idempotent module design: check current state, act only if different, report changed/unchanged - a report of 'changed' on every run signals non-idempotence.

Ansible: inventory defines hosts, playbooks map plays to host groups, roles bundle tasks/handlers/templates; handlers run once at play end when notified.

Order of operations matters: package install → config file render (template) → service restart via handler → health check.

Immutable vs mutable: configuration management mutates long-lived hosts; image baking bakes config into an artifact. Many shops use CM to build images, not to patch live servers.

Secrets belong in vaults (HashiCorp Vault, cloud secret managers) injected at runtime; ansible-vault encrypts files at rest but the key must be managed separately.

Automation guardrails: dry-run/check mode, blast-radius limits (serial/batch sizes), and canary hosts before fleet-wide rollout.

Configuration drift is measured by periodic compliance scans; a host failing its baseline is re-provisioned from the image rather than hand-fixed.

Three pillars: metrics (aggregated numbers over time), logs (discrete timestamped events), traces (causal spans across services). Observability is the ability to answer new questions from that telemetry.

Four golden signals: latency (distinguish success vs error latency), traffic, errors, saturation. USE method: utilization, saturation, errors per resource.

RED method for services: rate, errors, duration - the minimal per-service dashboard.

SLI is a measured indicator (e.g., fraction of requests <300 ms); SLO is the target (99.9%); error budget = 1 − SLO, and burn rate measures how fast it is consumed.

Percentiles over averages: p50/p95/p99 reveal tail latency; averages hide slow outliers. Aggregating percentiles across instances is invalid - aggregate raw histograms.

Alert on symptoms (SLO burn, error rate) rather than causes (CPU high); cause-based alerts produce noise and fatigue.

Log levels DEBUG/INFO/WARN/ERROR/FATAL; production defaults to INFO, and structured JSON logs with correlation/trace IDs enable cross-service joins.

Log aggregation pipeline: agent ships → buffer/queue → indexer → store; sampling and retention tiers control cost, and PII must be redacted before indexing.

Distributed tracing propagates a trace context (W3C traceparent) across services; a span records operation, duration, and parent, enabling critical-path analysis.

Pull vs push metrics: Prometheus scrapes exporters; push suits short-lived batch jobs via a gateway. Cardinality from high-dimension labels is the main cost driver.

Shift left: security controls run in the pipeline (SAST, dependency scanning, secret scanning, IaC scanning, container image scanning) before merge or deploy.

SAST analyzes source for coding flaws; DAST probes a running app for runtime vulnerabilities; SCA checks third-party dependencies against CVE/advisory databases.

Least privilege: CI/CD service accounts get scoped roles and short-lived credentials via OIDC federation, not long-lived static keys stored in CI variables.

Secrets management: never commit secrets; rotate on exposure; scanners (e.g., pre-commit hooks and repo history scans) detect leaked keys, and history rewriting plus revocation is required.

Supply chain integrity: pin dependencies and images by digest, generate an SBOM, sign artifacts (Sigstore/cosign), and verify signatures at admission.

Policy as code gates deployments (e.g., OPA/Rego, admission controllers) and enforces rules such as no public buckets or required resource tags.

Compliance evidence is generated continuously: pipeline logs, signed approvals, and drift reports map to controls (e.g., change management, access review) for audit.

Segregation of duties in pipelines: the person who approves a production change should not be the only one able to alter the pipeline definition; protected branches and approval gates enforce this.

Threat model the pipeline itself: compromised build agents can tamper with artifacts, so builds run in ephemeral, isolated runners with no persistent credentials.