Module 0 — Prerequisites & How to Use

Audience: Everyone starting the path — new hires and existing engineers upskilling.

Outcomes: Set up a personal lab, understand how verification works in this path, and adopt the “model before commands” mindset that every later module assumes.

Checklist — work through in order

• Read Why this module exists and adopt the “model before commands” mindset
• Stand up a lab you can reach by console + CLI
• Complete access onboarding (SSO, repo access, cluster access)
• Confirm you know where completion is recorded and who reviews it
• Pass the Verification checks at the bottom

Why this module exists

This path deliberately teaches models before commands. The single biggest obstacle to learning DevOps tooling is not missing knowledge — it is a mental model that needs rebuilding, not extending. Each module opens with the mental shift required. Treat the lab as non-negotiable: every concept should map to something you can inspect in a console or from a CLI.

Topics

• Lab options — a single local cluster (or cloud trial) for Modules 1–4; a hub + managed cluster for Modules 5–6; bare-metal/simulated nodes for Module 8.
• Verification philosophy — scenario-based checks, not flash-card recall. If you need notes to do the check, the module is not done.
• Beginner’s mind — some prior knowledge transfers; much does not. Anchor too hard on old analogies (e.g., “clusters are like vCenters”) and the gaps get harder to find.
• Pace — self-paced. Modules 1–2 are days; Modules 3–7 are weeks. Module 8 is a specialist track.

Resources

Verification

1. You have a working lab environment you can ssh/CLI into.
2. You can state, without notes, the difference between learning a command and learning a model, and why this path leads with the model.
3. You know where to record completion and who reviews it.

Module 1 — Git, GitHub & GitLab Best Practices

Audience: Anyone using Git day to day — developers, writers, infrastructure and platform engineers. If you’ve used Git but not internalized why the model works, this module is for you.

Outcomes: Understand how Git stores history (the inside-out mental model); use the daily workflow (clone → branch → commit → push → PR/MR → merge) without looking up commands; reason about git log, diff, revert; operate comfortably in both GitHub and GitLab with branch protection, CODEOWNERS, and SSO/SAML; and earn the GitHub Foundations certification.

Checklist — work through in order

• Stage 0 (do first): watch Git For Ages 4 And Up and draw the object model
• Stage 1: Microsoft Learn — GitHub Fundamentals path + GitHub Skills (in-browser); GitLab users add GitLab for Beginners
• Stage 2: finish learngitbranching.js.org “Introduction Sequence” + “Ramping Up”; read Pro Git Ch.1–3
• Work the Mechanics checklist (clone/branch/commit/push/PR, diff, log, revert vs reset, CODEOWNERS, branch protection)
• Complete enterprise hosting onboarding (SSO-authorized PAT, 2FA)
• Certify: book GitHub Foundations (GitHub/PSI · $99 · 75 questions · 120 min · 700/1000 · no prerequisites). Study aids: Microsoft Learn GitHub Fundamentals, Pro Git, LadyKerr github-certification-guide
• Pass the scenario-based Verification at the bottom

Mental model first — not just “how to Git”

Most Git tutorials start with commands. This module starts with the model, because commands make no sense without it. Git stores snapshots, not diffs; commits are immutable, content-addressed objects; branches are labels, not containers. Every confusing moment (detached HEAD, merge vs rebase, rejected pushes) is a model mismatch.

Do Stage 0 before anything else.

Git vs Git hosting platforms

• Git = decentralized version control (created by Linus Torvalds, 2005). Every developer has the full history. Identical everywhere it’s installed.
• GitHub / GitLab = hosting services on top of Git: web UI, PRs/MRs, issues, CI/CD, wikis. The collaborative layer differs; Git itself does not care which host you use.
• Core workflow is identical on both: clone → checkout -b feature → add → commit → push -u origin feature → open PR (GitHub) / MR (GitLab).

Git as the tool for change management

Git doesn’t create governance — the workflows on top do. This reframe is the cultural core of everything later (especially GitOps).

Git makes governance faster, more traceable, and automatable at the enforcement layer.

Stage 0 — Mental model (free, ~2h)

Git For Ages 4 And Up — Michael Schwern (~1h 40m). Teaches objects → commits → labels → staging → remotes with physical props. After this, detached HEAD, rebase, and reset become logical consequences of the model.

Verification: On paper/whiteboard, draw the relationship between a blob, a tree, a commit object, a branch label, HEAD, and a remote ref. Explain what git commit physically does to those objects.

Stage 1 — Hands-on basics (free, 2–4h)

Verification: Clone a repo, create a branch, edit one line, commit, push, open a PR/MR. Write the description as a change ticket: what changed, why, risk, how to verify.

Stage 2 — Internals & interactive practice (free)

Verification: Complete “Introduction Sequence” + “Ramping Up” of learngitbranching. Explain, without notes, git rebase main vs git merge main on a feature branch.

Mechanics checklist (Day-to-day GitOps work)

Enterprise hosting notes

• Complete IT device/token onboarding before pushing — PATs often need one-time SSO authorization.
• Prefer fine-grained PATs (or deploy keys / service-account tokens for CI) over classic repo-scoped tokens.

Certification

Verification (scenario-based)

1. Clone → branch → edit → push → PR: as above, with ticket-style description.
2. Explain the model: without notes — git commit (local) vs git push (publish); git pull (laptop) vs merging a PR/MR (review gates, approval record, audit).
3. Read history: from git log, answer who changed deployment.yaml two weeks ago, what, and was it reviewed?
4. Recover: make a bad commit on a feature branch; git revert it; explain why not git reset on a shared branch.

Module 2 — Containers & Registries

Audience: Engineers new to containerization, or coming from VM-centric operations.

Outcomes: Build and run container images; understand the layer model, image digests, and registries; reason about base images, tags vs digests, and registry authentication — the foundation for Kubernetes (Module 3).

Checklist — work through in order

• Read the mental model below (images, layers, tags vs digests, Podman vs Docker)
• Learn containers before Kubernetes — do a Docker/Podman fundamentals course: KodeKloud “Docker for the Absolute Beginner” or Podman docs getting-started
• Build and run your first image from a minimal base (UBI/distroless)
• DO180 (Red Hat: Containers, Kubernetes & OpenShift) as the formal path — free Red Hat Developer tutorials as a no-cost alternative
• Practice registry push/pull, tags vs digests, and image scanning
• Pass the scenario-based Verification at the bottom

Mental model

A container is an isolated, runnable instance of an image — an immutable, layered filesystem plus metadata. Unlike a VM, a container shares the host kernel and has no hypervisor. The unit Kubernetes reasons about is the container (packed into Pods), not the VM.

Key shifts from VM thinking:

• Images are immutable artifacts, not running state. You rebuild, not “snapshot and edit.”
• Layers are content-addressed and shared — changes only add new layers.
• Tags are mutable pointers; digests are immutable. Production should pin by digest.

Topics

• Images & layers — Dockerfile / Containerfile instructions; layer caching; minimal base images (UBI, distroless).
• Building & running — build, run, exec, logs, port/publish, volumes, environment.
• Registries — pull/push, tags vs digests, auth, mirror registries, private/internal registries.
• Image hygiene — sizing, non-root users, multistage builds, scanning for CVEs.
• Podman vs Docker — rootless containers; podman is OCI-compliant and often the platform default (no daemon).

Resources

• Red Hat — DO180: Containers, Kubernetes, and Red Hat OpenShift (formal course; containers + K8s intro).
• OpenShift learning (Red Hat Developer) — no-cost tutorials (URLs change; use as hub).
• Podman documentation — docs.podman.io; podman build/run mirror Docker CLI.

Verification (scenario-based)

1. Write a Containerfile for a small HTTP app from a minimal base image; build it; run it; curl the exposed port.
2. Inspect layers (podman history / docker history); explain which instruction added which layer and why caching matters.
3. Pull an image by tag, then by digest; explain why the digest is reproducible and the tag is not.
4. Push an image to a registry; explain auth and how a cluster later pulls it (ties to Module 3 image pulls + Module 8 disconnected mirrors).

Module 3 — Kubernetes & OpenShift Core

Audience: Infrastructure/platform engineers and developers operating or deploying on Kubernetes/OpenShift. (VMware admins: this is where you rebuild the mental model from Kubernetes up — see the mapping scaffold, then discard it.)

Outcomes: Read and reason about YAML; navigate console + CLI; deploy and diagnose a stateless app; operate cluster-level concerns — cluster operators, MachineConfig, nodes, auth, SCCs, OLM, multi-tenancy, networking, storage, observability, and backup/DR.

Checklist — work through in order

• Prereq: basic Linux (Red Hat RH124 or equivalent) — you will live on the CLI
• Read the Mental shift below and internalize desired-state / nodes-are-cattle
• 3.1 App layer — Deployments, Services, Routes/Ingress, ConfigMaps/Secrets, RBAC, Operators
• 3.2 Cluster ops — cluster operators, MachineConfig, nodes, OAuth, SCCs, OLM, observability, backup/DR
• 3.3 Networking — OVN-Kubernetes, NetworkPolicy, Multus/NAD, MetalLB, NMState
• 3.4 Storage — StorageClass, PV/PVC, CSI, ODF, RWX vs RWO
• Courses: KodeKloud “Kubernetes for the Absolute Beginners” / CKA / CKAD (Mumshad) for vendor-neutral depth; DO180 → DO280 for the OpenShift track
• Certify (optional, vendor-neutral): CNCF KCNA (entry) → CKAD or CKA (performance-based, 66% to pass, $445). OpenShift track: EX280 (Module 9)
• Pass the scenario-based Verification in each sub-section

Mental shift (read first)

OpenShift is a Kubernetes platform. OpenShift Virtualization (Module 4) is a Kubernetes add-on that runs VMs inside Kubernetes. The substrate is Kubernetes — not a hypervisor.

Treat vCenter/ESXi analogies as a temporary scaffold only. They break:

• Console is read/observe, not source of truth — Git is (Modules 5+).
• Nodes are cattle — drainable/replaceable; state lives in PVCs.
• Manifests are desired-state — controllers reconcile continuously; divergence is auto-corrected.

3.1 — Kubernetes internals & application layer (1–2 weeks)

Topics

• Images, registries, Deployments, Services, Routes/Ingress, ConfigMaps, Secrets
• Namespaces/Projects, RBAC — who can get what
• Operators — platform extends itself via CRDs (the same mechanism that adds VM support in Module 4)

Official

• Pods (Kubernetes docs) — the atom
• OpenShift learning (Red Hat Developer)
• An introduction to GitOps (read once so Module 5 connects)

Verification

• Given unseen Deployment YAML: identify image, replicas, port, env vars, volume mounts — unaided.
• Run a pod that fails (bad image tag / missing env). Diagnose with oc get pods, describe, logs, get events — no console.
• Expose an app with a Route; curl it; explain what the Route did and which operator manages it.

3.2 — Cluster operations (admin lens) (2–4 weeks, parallel with 3.1)

Topics

• Cluster operators — oc get co is the platform-health dashboard
• MachineConfig / MachineConfigPool — declarative node config (don’t SSH to fix nodes)
• Nodes — cordon, drain, conditions (maintenance-mode equivalent)
• Authentication — OAuth, identity providers; diagnose “can’t log in”
• Security Context Constraints (SCCs) — pod-level security model, no VMware equivalent; restricted-v2 default is stricter than upstream K8s. Audit with oc adm policy who-can use scc.
• Operator Lifecycle Manager (OLM) — CatalogSource, Subscription, InstallPlan, CSV. A CSV stuck Installing is the most common failure.
• Multi-tenancy — namespace isolation (ResourceQuota, LimitRange) vs separate clusters; RBAC for self-service.
• Observability — Prometheus + Alertmanager (default); PrometheusRule, AlertmanagerConfig; LokiStack logging; oc adm must-gather / oc adm inspect.
• Backup & DR — etcd backup (control-plane recovery); OADP/Velero for workload PVs. Two models: restore (etcd + node rebuild) vs rebuild (GitOps re-apply) — neither fully replaces the other.

Official

• OCP documentation — bookmark Operators, Nodes, Networking, Security
• Managing Security Context Constraints
• Backing up etcd
• OADP
• Monitoring overview

Verification

• oc get co; find a degraded operator; explain (via describe/events/logs) what’s wrong.
• (multi-node) Cordon → confirm no eviction; drain → confirm pods moved; uncordon. On SNO: trace the procedure and name constraints.
• SCCs: deploy a pod requesting hostNetwork: true; find the SCC failure; oc adm policy who-can use scc hostnetwork; explain restricted-v2 vs privileged.
• OLM: install via Subscription; break the channel; diagnose stuck InstallPlan/CSV; recover without deleting the operator.
• Observability: write a PrometheusRule firing when >10 pods Pending >5min; confirm in Alertmanager. Explain must-gather vs inspect.
• Backup/DR: run/trace an etcd backup; compare to a vSphere snapshot — what etcd preserves that GitOps rebuild can’t, and vice versa.

3.3 — Networking deep dive

• OVN-Kubernetes — default CNI; logical routers/switches managed via APIs, not a topology editor.
• NetworkPolicy — allow rules, not a firewall. Without any policy, all pod traffic is allowed.
• Multus CNI — multiple interfaces; primary via OVN, secondary via Multus (bridge/MACVLAN/IPVLAN).
• NetworkAttachmentDefinition (NAD) — CR defining a secondary network; VMs reference it in Module 4.
• MetalLB — LoadBalancer services on bare metal.
• NMState — declarative node networking (NodeNetworkConfigurationPolicy).
• SR-IOV — hardware virt for high-throughput/low-latency (telco/RAN).

Verification: Create a NAD bridge; attach a pod; confirm secondary interface; explain which component provisioned each. Write a default-deny + explicit-allow NetworkPolicy; confirm it blocks unlabeled traffic; explain why it is not an NSX firewall rule.

3.4 — Storage deep dive

• StorageClass — provisioner (CSI) + params; the datastore-type choice.
• PVC / PV — request vs provisioned; PVC persists independently of the pod.
• CSI — plugin API to storage back ends; swap back end = StorageClass change.
• ODF — Ceph-based SDS; RWX (CephFS) required for live migration (Module 4).
• DataVolume / CDI — how every VM disk is imported (Module 4).
• VolumeSnapshot / VolumeSnapshotClass — CSI point-in-time snapshots (data only, not memory).
• RWX vs RWO — live migration needs RWX.

Verification: Create PVC from default StorageClass; mount in pod; write file; delete pod; confirm persistence. Set reclaim Retain on another PVC; delete; find retained PV; explain next step. Explain why live migration needs RWX.

Module 4 — OpenShift Virtualization

Audience: Platform engineers who need to run and migrate VMs on Kubernetes/OpenShift.

Outcomes: Create, start, stop, and migrate VMs; connect storage/networking; understand KubeVirt primitives (VirtualMachine, VirtualMachineInstance, DataVolume) as Kubernetes resources — because that is what they are; perform live migration and plan bulk migration from vSphere (MTV).

Prerequisite: Module 3 substantially complete. A VirtualMachineInstance is a Pod — you cannot operate it without understanding Pods, scheduling, networking, and storage.

Checklist — work through in order

• Confirm Module 3 is substantially complete (a VMI is a Pod)
• Read the mental model + skim About OpenShift Virtualization
• Browse the Red Hat OpenShift Virtualization learning hub and kubevirt.io for the upstream project
• Create/start/stop a VM; find its backing VMI Pod
• Practice live migration (needs multi-node + RWX) and walk one MTV migration plan
• Formal course: DO317 — Managing VMs with OpenShift Virtualization (includes EX316 exam)
• Pass the scenario-based Verification at the bottom

Mental model

OpenShift Virtualization runs VMs inside Kubernetes via KubeVirt. The hypervisor is a process inside a Pod. The scheduler does not know or care it’s a VM. This is why Modules 2–3 come first.

Topics

• KubeVirt primitives — VirtualMachine (desired-state), VirtualMachineInstance (running Pod with hypervisor), DataVolume (managed PVC + import pipeline)
• VM networking — secondary networks via NAD; pod overlay (OVN) vs bridge-attached VLANs
• VM storage — DataVolume import (HTTP/registry/PVC clone); RWX requirement for live migration; VolumeSnapshot for disk backups
• Live migration — mechanism, objects (VirtualMachineInstanceMigration), shared-storage + node-scheduling requirements
• Migration Toolkit for Virtualization (MTV) — bulk vSphere import: source inventory, network maps, storage maps, cutover
• Performance tuning (read-ahead) — CPU pinning/NUMA (dedicatedCpuPlacement), HugePages, SR-IOV, real-time kernel, Node Tuning Operator

Official

• About OpenShift Virtualization
• Migrating VMs from vSphere (MTV)
• VMs as code with GitOps + Virt

Formal courses: DO317 — Managing VMs with OpenShift Virtualization (includes EX316 exam); DO156 Administration I as an alternative entry point.

Verification (scenario-based)

1. Create a VM from template/YAML; console/SSH in; find the backing VMI Pod via oc get pods; describe it; confirm it’s what Kubernetes schedules.
2. Live migration (multi-node + RWX required; not on SNO): migrate between workers; explain which K8s mechanisms determined placement. SNO fallback: trace every object (VirtualMachineInstanceMigration, source/target VMI pods, shared RWX PVC, QEMU channel); explain why SNO can’t (no valid target node) and the minimum topology.
3. Walk one MTV planning chapter: source inventory, network/storage maps, cutover — even if you migrate only one small VM.

Module 5 — CI/CD & GitOps

Audience: Engineers ready to apply Git-as-change-management to cluster configuration and application delivery.

Outcomes: Build CI/CD pipelines; use Argo CD (OpenShift GitOps) as the reconciliation engine; structure a multi-cluster GitOps repo; handle secrets safely; diagnose sync/drift and failure modes.

Depends on: Module 1 (Git) and Module 3 (cluster operations). Lab: one cluster + one Git repo is sufficient.

Checklist — work through in order

• Confirm Module 1 (Git) + Module 3 (cluster ops) are done
• Read the mental model (Git is source of truth; console is observe-only)
• Learn GitOps + Argo CD: Akuity Academy — Intro to GitOps & Argo CD (free, by the Argo creators) or KodeKloud/Coursera “Argo CD for the Absolute Beginners”. Argo CD is a CNCF Graduated project.
• Deploy your first Argo CD Application from Git; test drift + self-heal
• Learn ApplicationSet and app-of-apps; build the components/groups/clusters repo structure from the redhat-cop template
• Pick a secrets pattern (Sealed Secrets / External Secrets Operator)
• CI side: build a pipeline (GitHub Actions / GitLab CI / Tekton) that publishes images + manifests
• Pass the scenario-based Verification at the bottom

Mental model

A PR merge replaces a change ticket. A git revert replaces an emergency rollback. Argo CD closes the loop: it continuously reconciles what is in Git against what runs in the cluster. The console is read/observe only — changes made there do not survive a sync.

Topics

• OpenShift GitOps (Argo CD) — Application, AppProject, sync policies, health checks, self-healing
• ApplicationSet — generate many Applications from one template (by cluster label, directory, branch)
• App-of-apps — a root Application managing child Applications; full inventory lives in Git
• Configuration drift — what Argo CD detects; selfHeal vs manual sync
• Sync options — Validate, CreateNamespace, RespectIgnoreDifferences, retries
• GitOps repo structure — get this right early. Use the components / groups / clusters pattern:

components/   # atomic, reusable building blocks — one concern per subfolder
groups/       # composable cluster profiles (Kustomize Component, not overlay)
clusters/     # cluster-specific config — selects which groups to compose

Groups are Kustomize kind: Component (composable, not inherited) — a cluster can belong to all + non-prod + geo-east simultaneously. Reference redhat-cop/gitops-standards-repo-template and the 80+ component library redhat-cop/gitops-catalog as remote bases instead of writing operator YAML from scratch. A Helm variant uses mustMergeOverwrite with component-<name> keys.

• Mono-repo vs multi-repo — most teams start mono-repo, split when access control forces it.
• Secrets in GitOps — never commit plaintext/base64 secrets. Three patterns: (1) Sealed Secrets (asymmetric, in-cluster decrypt — simple); (2) External Secrets Operator (vault-backed, preferred for prod); (3) Helm Secrets / SOPS (encrypted values).

CI/CD (pipelines)

• Build/test/publish images and manifests in CI; let GitOps deliver to clusters.

Official

• Understanding OpenShift GitOps
• redhat-cop/gitops-standards-repo-template
• redhat-cop/gitops-catalog

Verification (scenario-based)

1. Create an Argo CD Application from Git. Change replica count/image tag in Git; watch convergence. Roll back via git revert; watch follow.
2. Introduce drift — change a resource via oc, bypassing Git. Confirm Argo CD detects/remediates per sync policy; explain why the console change didn’t survive.
3. Create an ApplicationSet generating one Application per directory; add a directory; confirm auto-creation.
4. Failure modes: push broken YAML (syntax error / missing field) — what state? How to find the sync error without console? Deploy a crashlooping pod — distinguish OutOfSync (differs from Git) from Degraded (matches Git but unhealthy); explain how both can be true.
5. Repo structure: clone the COP template; map each folder from kustomization.yaml only. Design groups/ for all + virt-enabled + edge-sno; explain how a cluster in both virt-enabled and edge-sno references both via kind: Component.
6. Catalog: find NMState/MetalLB/ESO bases in gitops-catalog; create components/nmstate/kustomization.yaml referencing the catalog; point an Application at it; confirm install.
7. Secrets: a teammate committed a base64 Secret. Explain exposure, remediate with Sealed Secrets vs ESO (why), and prevent recurrence via pre-commit hook or CODEOWNERS.

Module 6 — Fleet Management with ACM

Audience: Engineers operating multiple clusters who need consistency, compliance, and declarative correction at fleet scale.

Outcomes: Govern a fleet declaratively with RHACM — import clusters, target via labels, report compliance, enforce or inform, and bridge ACM + Argo CD (hybrid). Understand the decision framework: when should a config NOT be in Argo CD?

Prerequisite: Modules 3 and 5. Lab: hub cluster with ACM + OpenShift GitOps, plus ≥1 managed cluster. Single-node lab is insufficient.

Checklist — work through in order

• Read the fleet-thinking mental shift below (policy-first, not cluster-first)
• Stand up the lab: hub cluster with RHACM + OpenShift GitOps + ≥1 managed cluster
• RHACM governance & policy — ACM governance docs; import a cluster, label it, write your first policy
• Learn PolicyGenerator (YAML → policies) and Placements/PlacementBindings for label targeting
• Practice inform vs enforce and the Argo CD Application vs ACM Policy decision table
• DO432 (Multicluster Management with Red Hat Advanced Cluster Management for Kubernetes) → validates with EX432
• Complete the scenario-based verification at the bottom

Mental shift — fleet thinking

Topics

• Cluster lifecycle with ACM — import, label for targeting, view fleet compliance
• PolicyGenerator — YAML → RHACM policies via kustomize plugin
• Placements / PlacementBindings — label-based targeting
• inform vs enforce — detect/report vs auto-remediate
• PolicyAutomation — link a compliance event to an AAP job (ServiceNow, PagerDuty, Day-2 tasks)
• Ansible + ACM bridge — AAP generates CRs via Jinja (Redfish/Vault/DNS); ACM deploys; policies trigger AAP post-provisioning. Idempotent.
• Secret management — ESO + Vault back end (prereq for Module 8)

Key decision: Argo CD Application vs ACM Policy

Use ACM Policy for: NMState, cert-manager, Virt operator, file-integrity, OAuth, kubelet config, kubeadmin removal, pull-secret distribution. Use Argo CD for: team-owned operators varying by env/team.

Grey zone: a mandate on a heterogeneous fleet needing version variation → use ACM policy templating (Go-template against cluster labels), not a switch to Argo CD. The hybrid pattern: ACM delivers an Argo CD ApplicationSet to every cluster; ACM ensures the object exists, Argo CD reconciles content.

Official

• GitOps with ACM
• ACM governance
• PolicyGenerator integration

Verification (scenario-based)

1. Import a second cluster; label it; write a PolicyGenerator enforcing an RBAC/alertmanager rule on that label; confirm compliance in ACM console; flip inform→enforce; observe difference.
2. Explain fleet compliance without notes: what “non-compliant” means, who’s notified, monitoring vs remediation policy.
3. Scenario: Virt operator on all prod clusters (mandate) + Strimzi only on one team’s clusters. Argue the tool for each; what changes if Virt becomes a regulatory requirement?

Module 7 — Observability & Day-2 Operations

Audience: Engineers responsible for keeping workloads and clusters healthy, observable, and recoverable.

Outcomes: Monitor with Prometheus/Alertmanager; aggregate logs with Loki; define SLO-style alerts; back up and recover workloads (OADP) and the control plane (etcd); reason about the two recovery models.

Builds on: Module 3.2 (observability + backup/DR sections).

Checklist — work through in order

• Read the Day-2 mental model below (detect and recover, not click and hope)
• Metrics — Prometheus docs + OCP Monitoring; enable user-workload monitoring, write a PrometheusRule
• Dashboards & alerting — Grafana docs; wire Alertmanager routes
• Logs — deploy and query LokiStack (current logging backend)
• Diagnostics — practice oc adm must-gather vs oc adm inspect
• Backup & DR — OADP/Velero for workloads + etcd backup for the control plane; understand the two recovery models (restore vs rebuild)
• Complete the scenario-based verification at the bottom

Mental model

Day-2 operations is detect and recover, not click and hope. Observability tells you what’s wrong; backup/DR tells you how to get back. Both are declarative and version-controllable.

Topics

• Metrics — Prometheus + Alertmanager (installed by default); user-workload monitoring is opt-in (enableUserWorkload: true in cluster-monitoring ConfigMap). Key objects: PrometheusRule, AlertmanagerConfig.
• Logs — LokiStack is the current logging backend (replaced EFK/Elasticsearch).
• Diagnostics — oc adm must-gather (full snapshot for support/post-incident) vs oc adm inspect (targeted resource inspection).
• Fleet observability — ACM Observability aggregates hub-level metrics across managed clusters.
• Backup & DR — etcd backup = control-plane recovery (certs, cluster ID, custom CRs). OADP/Velero backs up workload namespaces, PVs, metadata to object storage; Virt VMs need the KubeVirt Velero plugin.
• Two recovery models: restore (etcd backup + node rebuild — recovers cluster state) vs rebuild (GitOps re-apply — recovers workloads but not cluster state). Neither replaces the other.

Official

• Monitoring overview
• OADP
• Backing up etcd

Verification (scenario-based)

1. Write a PrometheusRule firing when any namespace has >10 pods Pending >5min; confirm in Alertmanager. (Prereq: enable user-workload monitoring.)
2. Explain what oc adm must-gather collects and when to use it vs oc adm inspect.
3. Run/trace an etcd backup; describe contents, storage location, restore procedure. Compare to a vSphere snapshot: what etcd preserves that GitOps rebuild can’t, and vice versa.
4. Explain the OADP backup flow for a Virt VM and why the KubeVirt Velero plugin is required for consistent VM backup.

Module 8 — Zero Touch Provisioning (Specialist Track)

Who this is for: Teams managing 50+ clusters, especially remote/edge sites where manual install isn’t viable (retail, utility, telco). This is a distinct engineering specialty — Day 0/1/2 automation — beyond fleet operations. If you manage 3–20 clusters in a datacenter, Module 6 is sufficient; return here when provisioning becomes a bottleneck.

Outcomes: Automate the full cluster lifecycle — bare-metal prep through install into Day-2 — via the GitOps ZTP pipeline (SiteConfig, PolicyGenTemplate, TALM, ClusterGroupUpgrade, ClusterCurator/AAP, ESO).

Depends on: Modules 3–6 complete. ZTP uses Pods, operators, ACM policy, and Argo CD Applications internally.

Checklist — work through in order

Specialist track — complete Modules 3–6 first. This is Day 0/1/2 automation for 50+ cluster / edge fleets.

• Read the Day 0 / 1 / 2 framework below and the ZTP pipeline diagram
• RHACM edge computing / ZTP — ZTP at scale (OCP edge computing)
• Day 1 install — author a SiteConfig (+ AgentClusterInstall, infraenv, NMStateConfig); understand Assisted Installer + ApplicationSet-per-cluster
• Day 2 config — author a PolicyGenTemplate; orchestrate with TALM via ClusterGroupUpgrade (canary waves)
• Updating GitOps ZTP — updating the ZTP pipeline
• Secrets — wire ESO/vault for pull-secrets, BMH creds, certs (never in Git)
• Complete the scenario-based verification at the bottom

Day 0 / 1 / 2 framework

The ZTP pipeline

Git commit (SiteConfig / PolicyGenTemplate)
   → Argo CD (hub) applies CRs to ACM
   → ACM + Assisted Installer provisions cluster (Day 1)
   → TALM applies Day 2 policies via ClusterGroupUpgrade
   → Managed cluster: running, compliant, GitOps-managed

• Day 0 — ClusterCurator pre/post hooks run AAP jobs (network/storage/firmware checks).
• Day 1 — SiteConfig (+ AgentClusterInstall, infraenv, ManagedCluster, NMStateConfig) committed to Git; ApplicationSet auto-creates an Application per cluster directory.
• Day 2 — PolicyGenTemplate produces ACM policies; TALM orchestrates via ClusterGroupUpgrade (concurrency, canary, timeout). Upgrades follow the same Git-commit pattern.

Upgrade strategy depends on hardware: TALM in-place canary waves (no spare capacity), serial/parallel blue-green (spare pool or fast provisioning). Canary designation is the primary risk control for SNO fleets.

Secrets — ESO pulls pull-secrets, BMH creds, ingress certs, Htpasswd, ACM tokens from a vault at runtime. Never in Git.

Official

• ZTP at scale (OCP 4.19 edge computing)
• Updating GitOps ZTP
• TALM for cluster updates

Verification (scenario-based)

1. Commit a new SiteConfig directory; trace: ApplicationSet → Application → ACM ManagedCluster → Assisted Installer.
2. Write a PolicyGenTemplate installing the Virt operator on virt=enabled clusters; apply via TALM ClusterGroupUpgrade; confirm on managed cluster.
3. Trace a version-bump commit end-to-end: git push → Argo CD → ACM → PolicyGenTemplate → TALM → CGU → ClusterVersion operator.
4. Walk the ESO flow: where the secret lives, how ESO auths to vault, when the K8s Secret appears.

Module 9 — Certifications & Next Steps

Audience: Engineers planning formal credentials alongside the learning path.

Outcomes: Map each module to relevant public certifications, choose a sensible sequence, and identify deeper specializations.

Checklist — choose your track

• Pick a vendor-neutral track (portable across employers) and/or a Red Hat track (matches our OCP stack)
• GitHub Foundations (after Module 1) — GitHub/PSI, $99, 75Q, no prereq
• Linux base (Red Hat): RH124 → RH134 → RHCSA (EX200)
• Kubernetes (CNCF, vendor-neutral): KCNA (entry) → CKAD or CKA (66%, $445) → CKS (requires CKA)
• OpenShift (Red Hat): DO180 → DO280 → EX280; then DO317 (Virt + EX316 included), DO432 → EX432 (fleet)
• Book one exam with a target date; the rest follow the module sequence below

Certification map

Suggested sequencing

1. GitHub Foundations (Module 1) — early, low-cost, universally useful.
2. RHCSA (EX200) — if Linux is new to you; the base OCP assumes (RH124 → RH134 → EX200).
3. KCNA → CKA/CKAD after Module 3 — vendor-neutral, portable Kubernetes proof.
4. EX280 after Module 3 — validates core OCP admin on our stack.
5. EX432 after Module 6 — validates fleet governance for platform roles. Red Hat recommends DO280 → DO380 (optional) → DO432 as the prep path; DO380 covers cluster scaling and is useful but not required to attempt the exam.
6. Role-specific: DO317 (Virt, includes EX316) for virtualization focus; CKS (after CKA) for security; ZTP/specialist for edge fleets.

Beyond this path

• Contribute to internal runbooks; mentor the next cohort through Modules 0–1.
• Deepen weakest verification checks — they mark real operational gaps.
• Track upstream changes (course renumbers, ZTP tooling, ACM policy API) and update this path.

OpenShift Learning Curriculum

Purpose

This curriculum provides structured, role-based learning paths for engineers and support staff working with the OpenShift / RHOSV platform. Each path draws from a shared set of modules; the modules differ in depth and scope by role.

Philosophy: Learn the model before the commands. Most failures come from a wrong mental model, not a missing command. Every module front-loads the mental shift, then the mechanics. Treat the lab as non-negotiable — concepts should map to something you can inspect in a console or from a CLI.

Modules are maintained in learning-path/modules/. Each module page is self-contained: audience, outcomes, topics, curated resources, scenario-based verification, and <!-- ORG-SPECIFIC --> slots for internal details.

Role Paths

Platform / Infrastructure Engineers

Audience: Server engineers, platform engineers, and infrastructure engineers who build, operate, and extend the OpenShift platform.

Outcome: Full platform-engineering foundation — from Linux and Git fundamentals through cluster operations, virtualization, GitOps-driven delivery, fleet governance, observability, and (for specialists) zero-touch provisioning.

Suggested sequence: Complete modules in order. Module 3 is the largest — work through its sub-sections (app layer → cluster ops → networking → storage) before moving to Module 4.

Expected outcomes:

• Perform essential Linux administration tasks and live on the CLI
• Work confidently with Git, GitHub, and GitLab-based collaboration workflows
• Build, run, and reason about container images and registries
• Deploy, diagnose, and operate workloads and cluster-level concerns on Kubernetes/OpenShift
• Run and migrate VMs on Kubernetes via OpenShift Virtualization (KubeVirt)
• Build CI/CD pipelines and drive cluster state declaratively with Argo CD (GitOps)
• Govern a multi-cluster fleet with RHACM policies and compliance
• Monitor, alert, back up, and recover workloads and clusters
• (Specialist) Automate full cluster lifecycle via the GitOps ZTP pipeline

Support Engineers

Audience: Support staff who diagnose, triage, and escalate issues on the OpenShift platform. Operational and diagnostic depth; does not include pipeline engineering, GitOps authoring, fleet governance, or ZTP.

Outcome: Solid operational foundation — understand the platform model, navigate the CLI and console confidently, diagnose workload and cluster issues, and apply observability tooling to identify and escalate problems.

Modules 5 (CI/CD & GitOps), 6 (Fleet Management), and 8 (ZTP) are not included in the support path. Support staff should be consumers of the GitOps/fleet model — understanding that Git is the source of truth and the console is read/observe — but are not expected to author pipelines or ACM policies.

Suggested sequence: Complete modules in order. Skip from Module 4 directly to Module 7 — observability and diagnostics are the primary day-to-day toolset for support work.

Expected outcomes:

• Navigate the OpenShift console and CLI to inspect cluster and workload state
• Understand the container and Kubernetes model well enough to reason about failures
• Diagnose and triage VM issues on OpenShift Virtualization
• Use oc adm must-gather, oc adm inspect, Prometheus, and LokiStack to gather diagnostic data
• Understand backup/DR models (OADP/Velero, etcd) to support restore operations
• Escalate effectively with structured, evidence-based incident summaries

Module Library

All modules live in learning-path/modules/. Each is self-contained and can be read independently, though the paths above define the recommended sequence.