DevOps Study Guide

📖 Core Concepts DevOps – a cultural and technical movement that integrates development and operations, automating the software lifecycle to deliver changes faster while keeping quality high. Shared ownership – developers and ops jointly own the product, eliminating hand‑off silos. Workflow automation – repetitive tasks (build, test, deploy, monitoring) are scripted with tools (CI/CD pipelines, IaC). Rapid feedback – quick detection of failures enables fast iteration and continuous improvement. DORA metrics – four key performance indicators (Deployment Frequency, Lead Time for Changes, Change Failure Rate, Failed Deployment Recovery Time) that quantify DevOps effectiveness. Platform Engineering – builds internal developer platforms (standard CI/CD, provisioning, observability, security) for self‑service and consistency. GitOps – treats Git repositories as the single source of truth for deployment configuration; changes are made via pull requests and automatically applied. DevSecOps / SRE – extensions that embed security (DevSecOps) or reliability engineering (SRE) into the DevOps workflow. --- 📌 Must Remember DevOps Goal: Reduce commit‑to‑production time and maintain high quality. DORA Metric Targets (high performers): Deployment Frequency → multiple times per day Lead Time for Changes → < 1 hour Change Failure Rate → < 15 % Failed Deployment Recovery Time → < 1 hour Key Principles: Shared ownership, automation, rapid feedback, continuous improvement (kaizen/PDCA). GitOps Core: Desired state stored in Git; the system continuously reconciles live state to Git state. SRE vs DevOps: SRE is a practical implementation of DevOps for large‑scale services, focusing on SLIs/SLOs and error budgets. --- 🔄 Key Processes CI/CD Pipeline Flow Commit → Build → Automated Tests → Artifact Repository → Deploy to Staging → Acceptance Tests → Deploy to Production DORA Metric Collection Record timestamp at code commit → timestamp at deployment → compute lead time. Count deployments → compute frequency (e.g., per day). Track failures → calculate failure rate = (failed deployments ÷ total deployments) × 100 %. Measure time from failure detection to recovery → failed deployment recovery time. GitOps Reconciliation Loop Git commit → controller watches repo → diff between desired and actual state → apply changes → status report back to Git. DevSecOps “Shift‑Left” Testing Integrate SAST, SCA, DAST early in CI pipeline; fail the build on critical findings. --- 🔍 Key Comparisons DevOps vs ITIL – Bottom‑up, flexible, tool‑driven vs Top‑down, prescriptive, process‑centric. SRE vs DevSecOps – Reliability focus (SLIs/SLOs, error budgets) vs Security focus (shift‑left testing, vulnerability triage). Platform Engineering vs Traditional Ops – Self‑service, standardized pipelines vs Manual, ad‑hoc provisioning. GitOps vs Classic CI/CD – Git as source of truth for config + continuous reconciliation vs CI/CD only for code artifacts. --- ⚠️ Common Misunderstandings “DevOps = just tools.” – Tools enable automation, but cultural change (shared ownership, rapid feedback) is essential. “Higher deployment frequency always means better.” – Frequency must be paired with low change failure rate and fast recovery. “SRE replaces DevOps.” – SRE is a subset that operationalizes reliability; it coexists with broader DevOps practices. “GitOps eliminates all manual ops work.” – GitOps automates state reconciliation, but initial platform setup and exception handling still require ops expertise. --- 🧠 Mental Models / Intuition “Pipeline as a Production Line” – Think of each stage (build, test, deploy) as an assembly station; automation reduces bottlenecks, feedback loops catch defects early. “Feedback Loop Speed = Business Agility” – Shorter lead time = quicker market response; visualize a loop where each tick is a commit moving toward users. “Error Budget = Safety Valve” – SRE’s error budget lets teams know when to stop releasing and focus on reliability. --- 🚩 Exceptions & Edge Cases Large monoliths may have longer lead times despite automation; incremental refactoring or modularization may be needed. Regulated industries (e.g., finance, healthcare) often require manual approvals that break pure GitOps flows; hybrid pipelines are acceptable. Mobile DevOps must handle app store review cycles, adding an extra “approval” stage beyond standard CI/CD. --- 📍 When to Use Which Choose CI vs CD: Use Continuous Integration when you need rapid code integration and automated testing; add Continuous Delivery when you can automatically deploy to staging and want fast release cycles. GitOps vs Traditional Deploy: Prefer GitOps when you have declarative infrastructure (Kubernetes, Terraform) and want auditable, rollback‑ready deployments. Use classic CI/CD when you need custom scripts or non‑declarative environments. DevSecOps vs Separate Security Team: Adopt DevSecOps when security must be embedded early (fast release cadence); keep a separate team for deep threat modeling or compliance audits. Platform Engineering vs DIY Pipelines: Build a platform when multiple teams share common tooling needs; individual teams can stick with DIY pipelines for highly specialized workloads. --- 👀 Patterns to Recognize “Frequent small releases → low failure rate.” Spot questions that describe many tiny deployments and expect low change‑failure metrics. “Git commit → automatic rollback on failure.” Indicates a GitOps‑styled system. “Error budget exhausted → release freeze.” Signals SRE‑driven decision making. “Version‑controlled database schema + migration tests.” Points to Database DevOps practice. --- 🗂️ Exam Traps Distractor: “Higher deployment frequency always improves reliability.” – Wrong; without low failure rate & fast recovery, reliability can suffer. Distractor: “GitOps eliminates the need for monitoring.” – Incorrect; monitoring is still required to detect drift and performance issues. Distractor: “SRE is a separate methodology unrelated to DevOps.” – Misleading; SRE implements DevOps principles for reliability. Distractor: “DevSecOps only adds security scanning at the end of the pipeline.” – Wrong; the core idea is shifting left—security tests run early in CI. ---