CAPA Study Plan

CAPA is a 90-minute knowledge exam across four domains, but the four are nowhere near equal, and this plan is built around that fact rather than around a tidy four-way split. Argo Workflows is 36% of the paper — bigger than the famous Argo CD, at 34% — while Argo Rollouts (18%) and Argo Events (12%) are smaller surfaces worth proportionally less of your calendar. This page turns those four weights into a fourteen-day schedule: a study-hours budget funded by weight rather than by domain count, four project-by-project stretches each paired with the matching reading on the CAPA blueprint page and a real manifest to write from memory, a two-day lab that installs all four projects on one cluster, and a readiness gate you check honestly before opening a mock exam.

The arithmetic — funding days by weight, not by domain count

☺ Like you're 10: Fourteen days, four sections, and the split isn't one-quarter each — it's however big each section's real slice of the test actually is.

Pick a total number of study hours for the four domains — reading the blueprint page, writing manifests from memory, working the drills — kept separate from the two-day integration lab and the mock-exam days, which get their own budget below. Then apply one rule: no domain gets extra time because it's the famous one, and none gets shortchanged because it's the smallest. The CNCF's curriculum already decided how much each domain is worth; your only real decision is the total.

hours for a domain = total domain-study hours × that domain's weight.

This plan uses 20 hours of domain study across eleven days — a little under two hours a day, which is realistic for a 90-minute exam that doesn't need eleven-week devotion. Applying the four weights instead of splitting evenly produces this:

Say the headline fact plainly, because it's the one candidates get backwards most often: Argo Workflows, at 36%, outweighs Argo CD's 34%. Argo CD is the project with the dashboard everyone recognizes; Workflows is the one that quietly carries more of the exam. Fund your calendar by the number, not by which tool you've actually used at work.

The two-week calendar at a glance

Every section below is just a calendar wrapped around one row of this table. Read the matching part of the blueprint page first each day, then do the writing-from-memory task before you check your work against it — that order matters more than the reading itself.

Before Day 1 — pick your pace

☺ Like you're 10: Fourteen days is a guess about a specific kind of person. If that's not quite you yet, the plan stays the same shape — the number of days just changes.

"Fourteen days" assumes you're comfortable reading a Kubernetes manifest already — you don't need to have run Argo CD in production, but the core Kubernetes objects (Pod, Deployment, Service, custom resources in general) shouldn't be new vocabulary. If they are, this course's own Kubernetes Baseline You Need is worth a detour before Day 1.

Days 1–4 — Argo Workflows, the 36%

☺ Like you're 10: Four days on the to-do-list robot — because it's the single biggest chunk of the whole test, bigger than the famous one.

Read the Argo Workflows section of the blueprint page in full on Day 1, twice if you have time — the six template types (container, script, resource, suspend, steps, dag) are the vocabulary of the entire domain and are worth having cold before Day 2. On Days 2–3, write a Workflow with a dag template from memory: an extract step, two parallel steps that each depend on it, and a load step that depends on both — the exact fan-out/fan-in shape the "Run Data Processing Jobs" competency is pointing at. Don't copy the manifest from the blueprint page; write it cold, then diff your version against the reference and note every field you forgot.

# Day 2–3 target: write this from memory, then diff against capa-blueprint.html
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: study-plan-etl-
spec:
  entrypoint: pipeline
  templates:
    - name: pipeline
      dag:
        tasks:
          - name: extract
            template: extract
          - name: transform-a
            template: cruncher
            dependencies: [extract]        # fan-out
          - name: transform-b
            template: cruncher
            dependencies: [extract]
          - name: load
            template: loader
            dependencies: [transform-a, transform-b]   # fan-in
    - name: extract
      container: { image: acme/extract:1.0 }
      outputs:
        artifacts:
          - { name: raw, path: /out/raw.parquet }
    - name: cruncher
      inputs:
        artifacts:
          - { name: raw, path: /in/raw.parquet }
      container: { image: acme/crunch:1.0 }
    - name: loader
      container: { image: acme/load:1.0 }

On Day 4, add a WorkflowTemplate that wraps the same DAG so it can be referenced with templateRef, and a CronWorkflow that schedules it. Then read the Argo Workflows tool page for anything the blueprint's exam-focused summary compressed past.

Days 5–8 — Argo CD, the 34%

☺ Like you're 10: Four more days on the plan-matching robot — nearly as many as the biggest section, because 34% is still more than a third.

Read the Argo CD section of the blueprint page on Day 5, paying close attention to the one distinction the exam leans on hardest: an Application's sync status (Synced / OutOfSync — does live match Git?) is a different question from its health status (Healthy / Progressing / Degraded — is the live thing actually well?). On Day 6, write an Application spec from memory with a source.helm block, syncPolicy.automated with both prune and selfHeal, and one ignoreDifferences entry.

# Day 6 target: write this from memory, then diff against capa-blueprint.html
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata: { name: study-app, namespace: argocd }
spec:
  project: default
  source:
    repoURL: https://github.com/example/config.git
    targetRevision: main
    path: charts/study-app
    helm: { valueFiles: [values-prod.yaml] }
  destination: { server: https://kubernetes.default.svc, namespace: study-app }
  syncPolicy:
    automated: { prune: true, selfHeal: true }
    syncOptions: [CreateNamespace=true]
  ignoreDifferences:
    - { group: apps, kind: Deployment, jsonPointers: ["/spec/replicas"] }

On Day 7, drill "Identify Common Reconciliation Patterns" specifically — it's the competency worth the most thought and the one candidates most often under-study: sync waves ordering resources within one sync, resource hooks (PreSync, Sync, PostSync, SyncFail — a database migration is the canonical PreSync Job), App-of-Apps and ApplicationSet for fanning out to many Applications, and AppProject for tenancy. On Day 8, add a second Application with a kustomize: block instead of helm:, so both renderers the exam names explicitly have gone through your hands at least once.

Days 9–10 — Argo Rollouts, the 18%

☺ Like you're 10: Two days on the careful-swap robot — smaller than the first two sections, but still nearly a fifth of the grade.

Read the Argo Rollouts section of the blueprint page, then on Day 9 write a canary Rollout from memory with a steps list that alternates setWeight and pause, plus one analysis step referencing an AnalysisTemplate. The distinction to get exactly right, because "Describe Analysis Template and AnalysisRun" is a named competency: an AnalysisTemplate is the reusable definition — the metric query, the successCondition, the failureLimit; an AnalysisRun is the live instance the controller creates when a rollout actually reaches that step. Template is the recipe, run is the dish — say that sentence out loud until it's automatic.

On Day 10, sketch a blueGreen strategy instead, naming activeService, previewService and autoPromotionEnabled without looking them up, and write one sentence explaining why an aborted canary is deliberately left Degraded rather than silently retried.

Day 11 — Argo Events, the 12%

☺ Like you're 10: One focused evening on the doorbell robot — it's the smallest section, and its competencies only ask you to recognize things, not build them from scratch.

Argo Events is the one domain where "understand fundamentals and architecture" is the entire ask — recognition-level, not "work with" or "run" like the heavier domains. Read the blueprint page's Argo Events section once, then close it and draw the chain cold: EventSource → EventBus → Sensor → trigger. Name what each component is (a listener, a transport bus, a rule-matcher) and one concrete example of each — a webhook EventSource, a NATS EventBus, a Sensor that submits a Workflow when its dependency fires. That single sentence and its four nouns are worth more marks per minute of study than anything else on this page.

Days 12–13 — the integration lab: all four, one cluster

☺ Like you're 10: Two days building all four robots for real, on one toy factory floor, instead of just reading about them one at a time.

This is where the eleven days of reading turn into something that runs. On a local kind cluster, install all four projects and exercise one object of each kind — not because the exam checks your terminal, but because "here is a manifest, what happens next?" questions are far easier to answer once you've watched the real controller do it.

# Day 12 — bring the cluster and the delivery half of the family up
kind create cluster --name capa-study

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
kubectl create namespace argo
kubectl apply -n argo -f https://raw.githubusercontent.com/argoproj/argo-workflows/main/manifests/quick-start-minimal.yaml

# point an Application at a public Helm chart with selfHeal on, then
# kubectl scale the Deployment by hand and watch Argo CD revert it
kubectl apply -f application.yaml
kubectl -n study-app scale deploy/study-app --replicas=1   # selfHeal should undo this

# submit the DAG from Day 2–3, then watch the two parallel pods run
# side by side and "load" wait for both in the Argo Workflows UI
argo submit workflow.yaml -n argo --watch

# Day 13 — bring up progressive delivery and eventing, then break something on purpose
kubectl create namespace argo-rollouts
kubectl apply -n argo-rollouts -f https://github.com/argoproj/argo-rollouts/releases/latest/download/install.yaml
kubectl create namespace argo-events
kubectl apply -n argo-events -f https://raw.githubusercontent.com/argoproj/argo-events/stable/manifests/install.yaml
kubectl apply -n argo-events -f https://raw.githubusercontent.com/argoproj/argo-events/stable/manifests/install-validating-webhook.yaml

# start the Day 9 canary, then abort it mid-flight — note it stays
# Degraded on purpose instead of quietly retrying
kubectl argo rollouts get rollout study-app --watch
kubectl argo rollouts abort study-app

# apply the Day 11 EventSource + Sensor, curl the webhook, and watch
# a Workflow appear from nothing
curl -X POST http://localhost:12000/push -d '{}'

If a step misbehaves, that's the point — Drill — Diagnose a Stuck Argo CD Sync and Drill — Build a Data-Processing DAG walk the two most common failure shapes step by step if either project fights you. Narrate the competency each command demonstrates out loud as you go — it's the fastest way to notice a domain you've been reading past without actually understanding.

Day 14 — the readiness gate, then book

☺ Like you're 10: Before anyone lets you sit a real test, a handful of honest checks — one per robot, plus one for the whole factory.

Don't open Mock Exam Set 1 until every box below is genuinely true, not "true if I squint." Recognizing a correct answer next to three wrong ones is a lower bar than producing the same fact cold — this checklist is written to catch the difference while it's still cheap to close.

• ① The two big domains — 70% together
• I can name all six Argo Workflows template types and what each does, without looking
• I can explain the difference between an Application's sync status and its health status in one sentence each, and give an example where they disagree
• ② The two lighter domains — 30% together, still worth studying
• I can explain AnalysisTemplate vs. AnalysisRun in one sentence each — recipe vs. dish
• I can draw EventSource → EventBus → Sensor → trigger from memory, with one real example of each
• ③ The whole exam
• I ran all four projects on a real cluster during Days 12–13, not just read about them
• I could state, from memory, which domain is the biggest and which is smallest — and I studied in that order

Four or more checked, spanning at least two categories, is a reasonable green light. Fewer than that, don't force the calendar — go back to the specific day range above, not a general re-read of everything.

Once the gate is clear, work the CAPA practice questions, then sit Mock Exam Set 1 and Set 2 a day or two apart rather than back to back. After each, log every miss and re-read only the domain it came from.