CAPA — the exam

The Certified Argo Project Associate (CAPA) is the CNCF and Linux Foundation's associate-level badge for a family of four tools that share a name and not much else operationally: Argo Workflows, Argo CD, Argo Rollouts and Argo Events. It's a knowledge-based, 90-minute, multiple-choice exam — no terminal, no live cluster — that expects you to read Argo custom resources, name what each controller does, and pick the right one of the four for a job. On the Golden Kubestronaut ladder it's one of the nine project-specific associates this course covers, and it overlaps CGOA (which examines the GitOps specification, with Argo CD as one implementation of it) without duplicating it. This page lays out the four official domains and weights exactly as the CNCF publishes them, works through the substance of each with real manifests, and separates what the official pages state from what they don't.

What the CAPA is, and who it's for

☺ Like you're 10: It's a multiple-choice test on a computer, about four tools. Nobody watches you type real commands — they watch what you already know.

CAPA is knowledge-based: an online, remote-proctored, multiple-choice sitting. There is no cluster to drive and no kubectl to type — the exam tests whether you can read an Argo custom resource and say what happens next, not whether your hands are fast. That makes it the odd one out next to the five core Kubernetes certifications this course assumes (covered in full over in Kubernetes), which are almost all performance-based, live-terminal exams.

The scope is narrow and named: four products, not a discipline. You're expected to know the shape of a Workflow spec, what an AnalysisTemplate is for, how a Sensor relates to an EventSource, and how Argo CD renders Helm and Kustomize sources. If you've already read The Argo Ecosystem, most of the vocabulary below is a second pass, not a first one.

It suits platform and DevOps engineers who already run Argo CD daily and want the other three siblings properly rather than by rumour; release engineers who own promotion and rollback, since Rollouts is essentially their job description in CRD form; and data engineers, since "Run Data Processing Jobs with Argo Workflows" is a named competency and Workflows is the single biggest domain on the paper.

The four official domains & their weights

☺ Like you're 10: The test has four sections, and two of them are worth way more than the other two — the job-running robot and the plan-matching robot are two-thirds of the whole grade between them.

These come straight from the CNCF's published Certified Argo Project Associate (CAPA) Exam Curriculum — domain names, percentages, and the competency list below, not a paraphrase. Bars are drawn to scale against the largest domain:

Every competency, domain by domain

The full curriculum — four domains, sixteen competencies, exactly as the CNCF publishes them. The four weights sum to 100% (36 + 34 + 18 + 12); if a source you're reading doesn't add up to that, it isn't the official blueprint:

Two things worth noticing before you plan a study schedule. Workflows outweighs Argo CD, 36% to 34% — that surprises almost everyone, because Argo CD is the famous one with the nice dashboard. If you allocate study time by fame instead of by weight, you under-prepare the biggest third of the paper. And the competency verbs are graded: Argo Events only asks you to "understand" fundamentals and architecture — recognition-level — while Workflows asks you to "work with" DAGs and "run" data processing jobs, and Rollouts asks you to "describe" AnalysisTemplate and AnalysisRun. Read those verbs as a difficulty map.

Argo Workflows — the 36%

☺ Like you're 10: This is the to-do-list robot. It reads a list of jobs, does some one after another and some at the same time, and passes files between them.

Argo Workflows runs finite jobs on Kubernetes — every step is a pod, every pipeline is an API object. The unit you submit is a Workflow, whose spec has an entrypoint naming one of its templates. Know the template types cold; they're the vocabulary of the whole domain. The docs split them into definitions — container and script (run something), resource (create or patch a Kubernetes object), suspend (pause for a human or a timer) — and invocators, steps and dag, which compose the others. Those six are worth memorising; newer releases add containerSet, http, data and plugin on top, useful to recognise but not what the competency list is pointing at.

steps is a list of lists — sequential outer, parallel inner. A dag declares each task's dependencies and lets the controller derive order and parallelism. Reusability comes from WorkflowTemplate (namespaced) and ClusterWorkflowTemplate (cluster-scoped), referenced with templateRef, plus CronWorkflow for scheduling. Data moves two ways: parameters (small strings, via inputs.parameters / outputs.parameters) and artifacts (files, via inputs.artifacts / outputs.artifacts, through a repository — usually S3, GCS or MinIO).

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: telemetry-etl-
spec:
  entrypoint: pipeline
  arguments:
    parameters:
      - name: batch
        value: "2026-08-27"
  templates:
    - name: pipeline
      dag:                                    # the DAG template composes the others
        tasks:
          - name: extract
            template: extract
          - name: transform-spans
            template: cruncher
            dependencies: [extract]            # fan-out: spans and logs run in parallel
            arguments:
              artifacts:
                - name: raw
                  from: "{{tasks.extract.outputs.artifacts.raw}}"
          - name: transform-logs
            template: cruncher
            dependencies: [extract]
            arguments:
              artifacts:
                - name: raw
                  from: "{{tasks.extract.outputs.artifacts.raw}}"
          - name: load
            template: loader
            dependencies: [transform-spans, transform-logs]   # fan-in: waits for both

    - name: extract
      container:
        image: acme/telemetry-extract:2.1.0
        args: ["--batch", "{{workflow.parameters.batch}}"]
      outputs:
        artifacts:
          - name: raw
            path: /out/raw.parquet             # written to the artifact repository

    - name: cruncher
      inputs:
        artifacts:
          - name: raw
            path: /in/raw.parquet               # consumed from the artifact repository
      retryStrategy:
        limit: "3"
        retryPolicy: OnTransientError
      container:
        image: acme/crunch:2.1.0

    - name: loader
      container:
        image: acme/load:2.1.0

That single manifest touches five of the six Workflows competencies: the spec, templates, DAGs, artifacts, and the fan-out/fan-in shape that is a data-processing job. Add withItems or withParam for dynamic fan-out over a list and you have the map-reduce pattern the curriculum means by "Run Data Processing Jobs." Architecturally, remember the workflow-controller (reconciles Workflow objects into pods), the argo-server (API and UI), and the artifact repository configuration that trips up most first pipelines.

Argo CD — the 34%

☺ Like you're 10: This is the plan-matching robot. It holds a picture of what the factory floor should look like, drawn in Git, and it never stops nudging reality to match the picture.

Argo CD reconciles desired state from Git into a cluster, continuously. The unit is an Application: a source (repo, revision, path), a destination (cluster and namespace), and a syncPolicy. Two status fields answer two different questions, and the exam likes the distinction — sync status (Synced / OutOfSync: does live match Git?) and health status (Healthy / Progressing / Degraded: is the live thing actually well?). An Application can be perfectly Synced and thoroughly Degraded at once.

"Configure Argo CD with Helm and Kustomize" is a concrete competency — the repo-server renders your source before applying it, and the source block carries tool-specific options:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: mission-control-api
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/kubestronaut/platform-config.git
    targetRevision: main
    path: charts/mission-control-api
    helm:                                     # rendered by the repo-server
      releaseName: mission-control-api
      valueFiles: [values-prod.yaml]
      parameters:
        - name: image.tag
          value: "2.1.0"
    # kustomize:                               # the alternative renderer
    #   images: [kubestronaut/mission-control-api:2.1.0]
    #   namePrefix: prod-
  destination:
    server: https://kubernetes.default.svc
    namespace: mission-control
  syncPolicy:
    automated:
      prune: true                              # Git deletions become real deletions
      selfHeal: true                           # drift is reverted, continuously
    syncOptions:
      - CreateNamespace=true
  ignoreDifferences:                           # an HPA owns replicas; don't call that drift
    - group: apps
      kind: Deployment
      jsonPointers: ["/spec/replicas"]

"Identify Common Reconciliation Patterns" is the competency worth the most thought. Know self-heal (reverts out-of-band changes), prune (deletes what Git no longer declares), sync waves (argocd.argoproj.io/sync-wave orders resources within one sync), resource hooks (PreSync, Sync, PostSync, SyncFail, plus Skip and PostDelete — a database migration is the canonical PreSync Job), App-of-Apps and ApplicationSet for fan-out across many Applications, AppProject for tenancy boundaries, and ignoreDifferences for fields something else legitimately owns.

Argo Rollouts — the 18%

☺ Like you're 10: This is the careful-swap robot. It gives a new machine a little bit of the work first, checks nothing broke, and only then gives it more.

A plain Kubernetes Deployment can do a rolling update and nothing else — no pause, no traffic percentage, no automated abort. Rollout is a separate CRD that takes a Deployment's place: same replicas, selector and pod template, plus a strategy block offering canary and blueGreen (or you can leave the Deployment alone and point at it with workloadRef). For canary, the steps list is the whole idea: setWeight, pause, analysis, repeat. For blue/green, the vocabulary is activeService, previewService, autoPromotionEnabled and scaleDownDelaySeconds.

"Describe Analysis Template and AnalysisRun" is a distinction you must get exactly right. An AnalysisTemplate (or ClusterAnalysisTemplate) is the reusable definition — the metric query, its successCondition, the failureLimit. An AnalysisRun is the instance the controller creates when a rollout reaches an analysis step, carrying its own live status. Template is the recipe; run is the dish.

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: mission-control-api
spec:
  replicas: 6
  strategy:
    canary:
      steps:
        - setWeight: 10                        # 10% of traffic to the canary
        - pause: { duration: 5m }
        - analysis:                             # creates an AnalysisRun from the template
            templates:
              - templateName: success-rate
        - setWeight: 50
        - pause: {}                              # empty pause = wait for a human promote
  selector:
    matchLabels: { app: mission-control-api }
  template:                                      # the same pod template a Deployment carries
    metadata:
      labels: { app: mission-control-api }
    spec:
      containers:
        - name: mission-control-api
          image: kubestronaut/mission-control-api:2.1.0
---
apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: success-rate
spec:
  metrics:
    - name: success-rate
      interval: 1m
      failureLimit: 2                            # abort after 2 failed measurements
      successCondition: result[0] >= 0.99
      provider:
        prometheus:
          address: http://prometheus.monitoring:9090
          query: |
            sum(rate(http_requests_total{job="mission-control-api",code!~"5.."}[2m]))
            / sum(rate(http_requests_total{job="mission-control-api"}[2m]))

Two more things carry marks: traffic shifting needs a traffic router (an ingress controller, a service mesh, SMI or the Gateway API) or the weight is only approximated by pod counts; and an aborted rollout shifts traffic straight back to the stable ReplicaSet but is deliberately parked in a Degraded state rather than quietly retrying, so a human has to look at it.

Argo Events — the 12%

☺ Like you're 10: This is the doorbell robot. It listens for something happening outside and pokes another robot when it does.

Argo Events turns things that happen into Kubernetes objects that get created. It's the smallest domain, and its competencies only ask for fundamentals and architecture — so learn the three components and how a message flows between them.

apiVersion: argoproj.io/v1alpha1
kind: EventSource
metadata:
  name: git-webhook
spec:
  webhook:
    push:                                       # dependency name used by the Sensor
      port: "12000"
      endpoint: /push
      method: POST
---
apiVersion: argoproj.io/v1alpha1
kind: Sensor
metadata:
  name: on-push
spec:
  dependencies:
    - name: push-dep
      eventSourceName: git-webhook
      eventName: push                            # must match the EventSource key above
  triggers:
    - template:
        name: run-pipeline
        argoWorkflow:
          operation: submit                      # create a Workflow when the event arrives
          source:
            resource:
              apiVersion: argoproj.io/v1alpha1
              kind: Workflow
              metadata: { generateName: telemetry-etl- }
              spec:
                workflowTemplateRef: { name: etl-pipeline }

The exam-worthy sentence is the flow: EventSource → EventBus → Sensor → trigger. And the exam-worthy contrast: Argo Events is event-driven and creates objects on demand, whereas Argo CD is continuously reconciling whether or not anything happened at all.

Exam logistics — and how to verify them

☺ Like you're 10: It's an online test you take from home with someone watching through your webcam. Prices and timings change, so always check the official page before you pay.

Some facts about CAPA are structural and safe to state; others are exactly the sort the Linux Foundation revises without announcement. This table separates them deliberately, and this is an independent, unofficial study resource — not affiliated with the CNCF or the Linux Foundation.