topic_meta.json

{
  "core-devops-concepts": {
    "order": 1,
    "group": "Foundations",
    "description": "The vocabulary every DevOps interview opens with: what DevOps actually changes, why it exists, and how CI, continuous delivery, and continuous deployment differ.",
    "study_notes": [
      "Can you define DevOps without listing tools?",
      "The precise boundary between continuous delivery and continuous deployment.",
      "Which business metrics improve, and how you would measure them."
    ]
  },
  "docker": {
    "order": 2,
    "group": "Containers and Kubernetes",
    "description": "Container fundamentals - images versus containers, Dockerfile authoring, Compose, and the client/daemon architecture underneath `docker run`.",
    "study_notes": [
      "Image layers, the build cache, and how to keep images small.",
      "Why a container is not a virtual machine.",
      "Multi-stage builds and running as a non-root user."
    ]
  },
  "kubernetes": {
    "order": 3,
    "group": "Containers and Kubernetes",
    "description": "The control plane, the workload objects you touch daily, and the networking abstractions that make Pods reachable.",
    "study_notes": [
      "What each control-plane component does when you run `kubectl apply`.",
      "Service types and when each is appropriate.",
      "Why Pods are ephemeral and what that implies for state."
    ]
  },
  "cicd": {
    "order": 4,
    "group": "Delivery and Automation",
    "description": "Pipeline design, Jenkins and GitLab CI mechanics, and the delivery-versus-deployment distinction interviewers love to test.",
    "study_notes": [
      "Stages of a pipeline you have actually built, in order.",
      "How you keep pipelines fast and trustworthy.",
      "Where secrets and artifacts live in your pipeline."
    ]
  },
  "cloud-platforms": {
    "order": 5,
    "group": "Cloud Providers",
    "description": "Cloud service models and the three major providers - enough breadth to discuss AWS, Azure, and GCP comparatively.",
    "study_notes": [
      "IaaS / PaaS / SaaS boundaries and the shared responsibility model.",
      "Equivalent services across AWS, Azure, and GCP.",
      "Regions, availability zones, and how they shape architecture."
    ]
  },
  "infrastructure-as-code": {
    "order": 6,
    "group": "Delivery and Automation",
    "description": "Declarative infrastructure with Terraform and Ansible - state, providers, idempotency, and where each tool belongs.",
    "study_notes": [
      "Provisioning versus configuration management.",
      "How you manage Terraform state safely in a team.",
      "What makes a change idempotent."
    ]
  },
  "monitoring-and-logging": {
    "order": 7,
    "group": "Reliability and Operations",
    "description": "Metrics, logs, and the toolchain - Prometheus, Grafana, and the ELK stack - plus the conceptual split between monitoring and logging.",
    "study_notes": [
      "Pull versus push metric collection.",
      "What you alert on versus what you only dashboard.",
      "How logs get from a container to a searchable index."
    ]
  },
  "security-and-compliance": {
    "order": 8,
    "group": "Security",
    "description": "Shifting security left: DevSecOps practice, infrastructure and container hardening, and compliance expressed as code.",
    "study_notes": [
      "Where security gates belong in a pipeline, and what fails the build.",
      "How you handle secrets and image vulnerabilities.",
      "Turning a control framework into automated checks."
    ]
  },
  "linux-administration": {
    "order": 9,
    "group": "Foundations",
    "description": "The operating system under everything - commands, shell scripting, systemd, service management, and the filesystem hierarchy.",
    "study_notes": [
      "Diagnosing a slow or full host from the shell alone.",
      "Writing a safe, idempotent shell script.",
      "How systemd starts, supervises, and logs a service."
    ]
  },
  "version-control": {
    "order": 10,
    "group": "Foundations",
    "description": "Git mechanics and the branching models teams actually argue about, including how to resolve conflicts calmly.",
    "study_notes": [
      "Git Flow versus trunk-based development, and which suits continuous deployment.",
      "Merge versus rebase, and when each is safe.",
      "How you recover from a bad merge or a force push."
    ]
  },
  "configuration-management": {
    "order": 11,
    "group": "Delivery and Automation",
    "description": "Keeping fleets consistent with Puppet, Chef, Ansible, and Salt - push versus pull, agent versus agentless.",
    "study_notes": [
      "Desired state, drift, and convergence.",
      "Trade-offs between the major tools.",
      "Where configuration management ends and immutable infrastructure begins."
    ]
  },
  "scalability-and-high-availability": {
    "order": 12,
    "group": "Architecture and Scale",
    "description": "Designing systems that grow and stay up: scaling dimensions, load balancing, auto scaling, and recovery objectives.",
    "study_notes": [
      "Vertical versus horizontal scaling and the limits of each.",
      "Load-balancing algorithms and health checks.",
      "The difference between high availability and disaster recovery."
    ]
  },
  "backup-and-disaster-recovery": {
    "order": 13,
    "group": "Reliability and Operations",
    "description": "Backup types, RPO/RTO targets, business continuity planning, and the discipline of testing restores.",
    "study_notes": [
      "The 3-2-1 rule and why an untested backup is not a backup.",
      "Deriving RPO and RTO from business requirements.",
      "Costs and trade-offs of DR patterns from backup-restore to active-active."
    ]
  },
  "cloud-native-architecture": {
    "order": 14,
    "group": "Architecture and Scale",
    "description": "Microservices, service mesh, event-driven design, and the Twelve-Factor principles that make apps portable.",
    "study_notes": [
      "When a microservice split helps and when it hurts.",
      "How a mesh changes the responsibilities of application code.",
      "Config, state, and logs as Twelve-Factor treats them."
    ]
  },
  "performance-testing": {
    "order": 15,
    "group": "Architecture and Scale",
    "description": "Load, stress, soak, and spike testing - how to design them, which tools to use, and how to read the results.",
    "study_notes": [
      "Percentiles versus averages when reporting latency.",
      "How you build a realistic workload model.",
      "Turning a test result into a capacity decision."
    ]
  },
  "api-gateway-and-service-mesh": {
    "order": 16,
    "group": "Architecture and Scale",
    "description": "The API edge: gateway responsibilities, security, rate limiting, and documentation as a first-class artifact.",
    "study_notes": [
      "Gateway versus load balancer versus service mesh.",
      "Token-bucket rate limiting and how limits are communicated to clients.",
      "OAuth 2.0, OIDC, and where validation happens."
    ]
  },
  "container-orchestration-advanced": {
    "order": 17,
    "group": "Containers and Kubernetes",
    "description": "Beyond Deployments - StatefulSets, DaemonSets, Helm packaging, Istio, and the container runtime interface.",
    "study_notes": [
      "Why stateful workloads need stable identity and storage.",
      "How Helm templating and releases work, including rollback.",
      "What replaced Docker as the kubelet's runtime, and why."
    ]
  },
  "devops-tools-and-automation": {
    "order": 18,
    "group": "Delivery and Automation",
    "description": "GitOps with Argo CD, Tekton pipelines, and the deployment strategies used to ship without downtime.",
    "study_notes": [
      "Push-based CD versus pull-based GitOps reconciliation.",
      "Choosing between blue/green, canary, and rolling deploys.",
      "How drift is detected and corrected automatically."
    ]
  },
  "cloud-cost-optimization": {
    "order": 19,
    "group": "Cloud Providers",
    "description": "Reserved and spot capacity, tagging discipline, and the reports that turn a cloud bill into accountable engineering work.",
    "study_notes": [
      "Commitment options and their break-even points.",
      "Designing workloads that tolerate spot interruption.",
      "Making cost visible to the teams that create it."
    ]
  },
  "site-reliability-engineering": {
    "order": 20,
    "group": "Reliability and Operations",
    "description": "Google's operational model: SLIs, SLOs, error budgets, and the systematic elimination of toil.",
    "study_notes": [
      "Writing an SLI that reflects user experience.",
      "What an exhausted error budget should actually change.",
      "Which work counts as toil and how you cap it."
    ]
  },
  "devops-metrics-and-kpis": {
    "order": 21,
    "group": "Reliability and Operations",
    "description": "The four DORA metrics and the measurement habits that keep them honest.",
    "study_notes": [
      "Definitions of deployment frequency, lead time, change failure rate, and MTTR.",
      "How teams game each metric, and how to prevent it.",
      "Which metric you would improve first, and why."
    ]
  },
  "serverless-architecture": {
    "order": 22,
    "group": "Architecture and Scale",
    "description": "Functions as a service, the operational model behind them, and the design patterns that keep serverless workloads fast and cheap.",
    "study_notes": [
      "Cold starts and how to mitigate them.",
      "Statelessness, idempotency, and event-source semantics.",
      "When serverless is the wrong choice."
    ]
  },
  "database-management-in-devops": {
    "order": 23,
    "group": "Architecture and Scale",
    "description": "Treating schemas as code: version control, migration tooling, backup strategy, and performance tuning.",
    "study_notes": [
      "Running an online schema change with zero downtime.",
      "Expand/contract migrations and backward compatibility.",
      "Reading a slow query plan and acting on it."
    ]
  },
  "network-security": {
    "order": 24,
    "group": "Security",
    "description": "Zero trust, TLS, web application firewalls, and segmentation - the controls that protect traffic in and between clouds.",
    "study_notes": [
      "The TLS handshake and what certificate validation proves.",
      "Zero trust as an architecture, not a product.",
      "Segmentation at the network and Kubernetes-policy levels."
    ]
  },
  "incident-management": {
    "order": 25,
    "group": "Reliability and Operations",
    "description": "Detection through post-mortem: response plans, severity levels, on-call practice, and blameless learning.",
    "study_notes": [
      "Roles during an incident and who declares severity.",
      "What a good post-mortem produces beyond a document.",
      "Designing an on-call rotation people can sustain."
    ]
  },
  "devops-culture-and-practices": {
    "order": 26,
    "group": "Platform and Leadership",
    "description": "The human half of DevOps - shared ownership, blamelessness, knowledge sharing, and collaboration that survives incidents.",
    "study_notes": [
      "How you would change a team that treats operations as someone else's job.",
      "Making a post-incident review genuinely blameless.",
      "Documentation practices that outlive their authors."
    ]
  },
  "infrastructure-monitoring": {
    "order": 27,
    "group": "Reliability and Operations",
    "description": "Host and platform monitoring, APM, log management, and the practices that keep dashboards and alerts useful.",
    "study_notes": [
      "The USE and RED methods for choosing what to measure.",
      "Distributed tracing and where it beats logs.",
      "Alert fatigue and how to design it away."
    ]
  },
  "cloud-migration": {
    "order": 28,
    "group": "Cloud Providers",
    "description": "Assessment, the 6 Rs, application modernization, and the tooling that moves workloads without surprises.",
    "study_notes": [
      "Picking a migration strategy per application, not per portfolio.",
      "How you cut over with minimal downtime and a rollback plan.",
      "Discovery and dependency mapping before any move."
    ]
  },
  "advanced-devops-cloud": {
    "order": 29,
    "group": "Platform and Leadership",
    "description": "Senior-level ground: platform engineering, FinOps, policy as code, chaos engineering, observability, and progressive delivery.",
    "study_notes": [
      "Treating the internal platform as a product with users.",
      "Designing a chaos experiment with a hypothesis and a blast radius.",
      "Automating governance so policy is enforced, not asked for."
    ]
  },
  "devsecops": {
    "order": 30,
    "group": "Security",
    "description": "Security built into the delivery pipeline: scanning layers, SBOMs and supply-chain provenance, image signing, secretless pipelines, and vulnerability triage that does not stall delivery.",
    "study_notes": [
      "Which gates block a build, and how you handle the existing backlog.",
      "SBOM, provenance, and signature verification that fails closed.",
      "Ranking vulnerabilities by exploitability and exposure, not CVSS alone."
    ]
  },
  "secops": {
    "order": 31,
    "group": "Security",
    "description": "Security operations for engineers: SOC workflow, SIEM and normalisation, detection engineering, MITRE ATT&CK coverage, threat hunting, and security incident response.",
    "study_notes": [
      "Detecting behaviour rather than artifacts, and validating the detection.",
      "Preserving evidence before containment during a security incident.",
      "Which telemetry you would onboard first, and why identity logs come top."
    ]
  },
  "slo-engineering": {
    "order": 32,
    "group": "Reliability and Operations",
    "description": "The engineering practice behind SLOs: choosing targets, burn-rate alerting, correct latency SLIs, error budget policies, and SLOs for batch, async, and third-party dependencies.",
    "study_notes": [
      "Multi-window multi-burn-rate alerting, and why the short window exists.",
      "Latency as a threshold ratio rather than a percentile value.",
      "Owning the SLO even when the failing dependency is not yours."
    ]
  },
  "sla-management": {
    "order": 33,
    "group": "Reliability and Operations",
    "description": "The commercial side of reliability: SLA versus SLO versus OLA, downtime and composite availability arithmetic, contract clauses, service credits, reporting, and breach response.",
    "study_notes": [
      "Allowed downtime per target, and composite availability across dependencies.",
      "Why measurement definitions and exclusions cause more disputes than the number.",
      "What you do - commercially and technically - when you breach."
    ]
  },
  "aws-engineering": {
    "order": 34,
    "group": "Cloud Providers",
    "description": "Depth on AWS: VPC design, IAM policy evaluation, ECS/EKS/Fargate, Auto Scaling with load balancers, S3 storage classes, highly available databases, multi-account organisations, and IaC choices.",
    "study_notes": [
      "How IAM evaluates a request, including SCPs and cross-account access.",
      "Why the account is the blast-radius boundary.",
      "Making an application survive a database failover."
    ]
  },
  "azure-engineering": {
    "order": 35,
    "group": "Cloud Providers",
    "description": "Depth on Azure: the resource hierarchy, Entra ID and RBAC, VNet and private endpoint design, AKS, Bicep, Azure Policy and landing zones, Azure Monitor with KQL, and the compute options.",
    "study_notes": [
      "Management groups, subscriptions, and resource groups - what each bounds.",
      "Private endpoints and the private DNS configuration they depend on.",
      "Azure Policy effects, and rolling out Deny without breaking teams."
    ]
  },
  "gcp-engineering": {
    "order": 36,
    "group": "Cloud Providers",
    "description": "Depth on Google Cloud: resource hierarchy and org policies, IAM without service-account keys, the global VPC, GKE Standard versus Autopilot, Cloud Run, Cloud Operations, IaC, and the data services.",
    "study_notes": [
      "Why a global VPC changes multi-region design.",
      "Workload Identity Federation instead of service-account keys.",
      "Choosing between Cloud SQL, Spanner, and BigQuery by requirement."
    ]
  },
  "cloud-engineering": {
    "order": 37,
    "group": "Cloud Providers",
    "description": "Provider-neutral cloud engineering: landing zones, hybrid connectivity, least-privilege identity, multi-region resilience, multi-cloud trade-offs, DNS and global routing, and cross-provider service mapping.",
    "study_notes": [
      "Right-sizing a landing zone instead of copying the enterprise template.",
      "Recovery objectives first, then the cheapest pattern that meets them.",
      "Translating fluently between AWS, Azure, and GCP - including where it breaks."
    ]
  },
  "platform-engineering": {
    "order": 38,
    "group": "Platform and Leadership",
    "description": "Building the internal platform as a product: IDPs, golden paths, Backstage, Crossplane, self-service environments, adoption metrics, and safe rollout of breaking platform changes.",
    "study_notes": [
      "Golden paths that are chosen, not mandated - and escapable abstractions.",
      "Measuring adoption and developer outcomes rather than components shipped.",
      "Versioning the platform interface and automating consumer migrations."
    ]
  },
  "scripting-and-automation": {
    "order": 39,
    "group": "Foundations",
    "description": "The scripting layer under every pipeline - defensive Bash for orchestration, and Python for cloud APIs, structured data, and the tooling Bash cannot carry.",
    "study_notes": [
      "What `set -euo pipefail` does, line by line.",
      "Whether your script is safe to run twice.",
      "When you stop writing Bash and reach for Python."
    ]
  },
  "interview-experience": {
    "order": 40,
    "group": "Interview Prep",
    "description": "How the interview itself works - the round structure, explaining your project, answering scenario questions, and the company-by-company record of what was actually asked across 85 employers.",
    "study_notes": [
      "A rehearsed 90-second walkthrough of your current project.",
      "A justification for every technology choice you name.",
      "A method for scenario questions that ends in prevention, not just a fix.",
      "The specific questions your target company has actually asked before."
    ]
  }
}