CAPA — Certified Argo Project Associate

The Certified Argo Project Associate (CAPA) is the CNCF and Linux Foundation’s associate-level credential for one family of tools: Argo Workflows, Argo CD, Argo Rollouts and Argo Events. For a platform engineer that is an unusually practical shelf of knowledge — the Argo projects sit at the centre of most cloud-native delivery stacks, and three of the four appear on the CNPE tool list. This page covers what the exam is, whether it earns its price, the four official domains and weights exactly as the CNCF publishes them, the substance behind each, and a study plan assembled from lessons already on this site.

What the CAPA is — and who it is for

☺ Like you’re 10: It’s an online multiple-choice test about four related tools. You won’t have to type commands at a real cluster — you have to know what each tool does and what its YAML looks like.

The CAPA is knowledge-based: multiple-choice questions in an online, remote-proctored sitting, with no terminal and no live cluster. It certifies that you can read Argo custom resources, explain what each controller does, and choose the right project for a job — not that your fingers can drive argo submit at speed.

The scope is narrow and named. Where CGOA examines the GitOps specification and treats Argo CD as one implementation of it, CAPA goes the other way: it examines the products. You are 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.

Knowledge-based, not hands-on

That said, the surest way to pass a knowledge exam about YAML-driven controllers is to write the YAML. The commonest question shape is “here is a manifest, or here is a scenario — what happens, or which field do you change?” That is far easier to answer if you have watched the thing run once.

Who should sit it

• Platform and DevOps engineers who already run Argo CD and want the other three siblings properly, rather than by rumour.
• Release engineers and SREs who own promotion and rollback — the Rollouts domain is your job description in CRD form.
• Data and ML engineers — “Run Data Processing Jobs with Argo Workflows” is a named competency, and Workflows is the biggest domain on the paper. See AI/ML platforms.
• Application developers whose deployments go through Argo CD and who would like to understand the dashboard they stare at.
• CNPE and CNPA candidates shoring up the delivery half of those blueprints.

Why a platform engineer would take it — and when to skip it

☺ Like you’re 10: These four tools show up all over the harder platform exams, so learning them does double duty. But if you already use them every day, the badge won’t teach you much you don’t know.

Be honest about the return. CAPA is a vendor-adjacent associate credential — it certifies knowledge of one project family, not a discipline. Nobody is hired on a CAPA alone. Its value to a platform engineer is coverage and correction.

The overlap with the CNPE is real but partial

The CNPE’s GitOps & Continuous Delivery domain is 25% of that exam, joint-largest, and its tool list simply says “Argo.” Argo CD, Rollouts and Workflows all sit inside it, so roughly 88% of the CAPA blueprint (the three domains other than Events) feeds directly into a quarter of the CNPE — at reading depth rather than typing depth. The correction is the useful part: most engineers know Argo CD well and the other three barely at all, and CAPA forces you to fix exactly that imbalance. Workflows and Rollouts together are 54% of this paper.

When to skip it

Skip it if any of these hold. You operate all four projects already — if you have debugged an OutOfSync Application, an AnalysisRun that failed on a bad Prometheus query, and a Sensor whose EventBus was down, spend the money on a performance exam instead. Your platform runs Flux and Tekton — you would be certifying the stack you don’t use; CGOA is the tool-agnostic alternative. You need one certification for a hiring filter — recruiters screen for CKA far more than for project-specific associate badges. Otherwise, take it: it is a cheap, fast forcing function for the three siblings you don’t know. The certifications overview shows where it really sits on the shelf.

The four official domains & their weights

☺ Like you’re 10: The test has four parts and they are very unequal. The job-running robot and the plan-matching robot are two-thirds of the whole thing between them.

These come straight from the CNCF’s published Certified Argo Project Associate (CAPA) Exam Curriculum — the domain names, the percentages and the competency lists below are that document, not a paraphrase. The 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 page you are reading does not add up, it is not the official blueprint:

Reading the shape of this blueprint

Three things jump out. First: Workflows is the biggest domain, at 36% — bigger than Argo CD. That surprises nearly everyone, because Argo CD is the famous one. If you budget your study time by fame rather than by weight, you will under-prepare the largest third of the paper.

Second: Workflows and Argo CD are 70% together. Get those two genuinely solid and the exam is mostly won; Rollouts and Events are worth 30% between them and are far smaller surface areas.

Third: the competency verbs are graded. Argo Events asks only that you “understand” fundamentals and architecture — recognition-level. Workflows asks you to “work with” DAGs and “run” data processing jobs. Argo Rollouts asks you to “describe” AnalysisTemplate and AnalysisRun. Read those verbs as a difficulty map and study accordingly.

What you actually need to know

☺ Like you’re 10: Here’s the real substance — the four robots, the YAML each one reads, and the words you’ll be asked to match to the right robot.

Argo Workflows — the 36%

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, because they are 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 the set worth memorising; recent releases add containerSet, http, data and plugin on top, which are useful to recognise but are 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 the controller derives the order and the parallelism. Reusability comes from WorkflowTemplate (namespaced) and ClusterWorkflowTemplate (cluster-scoped), referenced with templateRef, and from CronWorkflow for scheduling. Data movement is parameters (small strings, passed via inputs.parameters / outputs.parameters) and artifacts (files, passed via inputs.artifacts / outputs.artifacts through an artifact repository — usually S3, GCS or MinIO).

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

    - name: extract
      container:
        image: acme/extract:1.4.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:1.4.0

    - name: loader
      container:
        image: acme/load:1.4.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 so many first pipelines get wrong. Full detail lives in the Argo Workflows page.

Argo CD — the 34%

Argo CD reconciles desired state from Git into a cluster, forever. The unit is an Application: a source (repo, revision, path), a destination (cluster and namespace), and a syncPolicy. Two status fields are separate 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 app can be perfectly Synced and thoroughly Degraded.

The “Configure Argo CD with Helm and Kustomize” competency is concrete: 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: checkout
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/acme/platform-config.git
    targetRevision: main
    path: charts/checkout
    helm:                                   # rendered by the repo-server
      releaseName: checkout
      valueFiles: [values-prod.yaml]
      parameters:
        - name: image.tag
          value: "1.4.3"
    # kustomize:                            # the alternative renderer
    #   images: [acme/checkout:1.4.3]
    #   namePrefix: prod-
  destination:
    server: https://kubernetes.default.svc
    namespace: checkout
  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 (revert out-of-band changes), prune (delete 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, AppProject for tenancy boundaries, and ignoreDifferences for fields something else legitimately owns. The Argo CD page and GitOps workflows cover all of it.

Argo Rollouts — the 18%

A 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. (You can also 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 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, with its own status. Template is the recipe; run is the dish.

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: checkout
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: checkout }
  template:                                 # the same pod template a Deployment carries
    metadata:
      labels: { app: checkout }
    spec:
      containers:
        - name: checkout
          image: acme/checkout:1.4.3
---
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="checkout",code!~"5.."}[2m]))
            / sum(rate(http_requests_total{job="checkout"}[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 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 Rollouts, CI/CD & progressive delivery and Flagger (the main alternative) go deeper.

Argo Events — the 12%

Argo Events turns things that happen into Kubernetes objects that get created. It is the smallest domain and the competencies ask only 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: 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. If you have met KEDA, note the difference — KEDA scales workloads from event backlogs; Argo Events creates workloads from event occurrences.

How to prepare using this site

☺ Like you’re 10: Three of the four robots already have a whole page here. Read them in weight order and you’ve read most of the syllabus.

This course was written for the CNPE, and the Argo family is all over its tool list, so CAPA is well covered here — with one honest gap, flagged below. Study in weight order: Workflows first (the biggest and the one you probably know least), then Argo CD, then Rollouts, then Events.

Domain-by-domain study map

Round it out with the glossary for terminology, flashcards for retrieval, Know It Cold for the manifests worth memorising, and the GitOps practice set for the Argo CD third.

A two-week pace

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 the CAPA are structural and safe to state; others are exactly the sort the Linux Foundation revises without announcement. This page separates them deliberately.

What the official pages state

Everything in this table is taken from the Linux Foundation’s CAPA page and the CNCF’s CAPA certification page, read at the time of writing (2026). Where the two agree, the figure is quoted; where neither publishes a number, the row says so rather than guessing.

What is not published — and what you must confirm yourself

Of the two figures candidates most want, only one is genuinely missing: the number of questions. Neither the CNCF nor the Linux Foundation publishes it, third-party sites quote “around sixty questions” with great confidence, and that figure comes from candidate reports rather than from either body — treat it as folklore and plan for a 90-minute paper you cannot rush. The cut score, however, is published, just not on the CAPA product page: the Linux Foundation’s Multiple Choice Exam FAQ states that “a score of 75% or above must be earned to pass the Multiple Choice Exam”, and CAPA is one. So 75% is the bar — not a rumour, and not a number you should be scraping. One further thing you can rely on: Linux Foundation multiple-choice exams are closed-book, so unlike the performance-based CKA/CKAD/CKS sittings there is no documentation tab to fall back on. Everything in the table above is a snapshot; prices, windows, retake terms and even domain weights get revised without announcement.

↗ Official CAPA page — Linux Foundation ◆ CNCF certification page ◆ Official CNCF curriculum repository ◆ The Argo Project — official docs for all four

Where it sits in the ladder — and what to do next

☺ Like you’re 10: This is a small first badge about one family of tools. From here you go either deeper into building platforms, or wider across the other badges.

CAPA sits on the associate rung, next to KCNA (Kubernetes fundamentals), KCSA (security fundamentals), CGOA (GitOps as a specification) and CNPA (platform engineering fundamentals). None of them gate anything, and CAPA is the most product-specific of the group. The certifications overview lays out the whole shelf and the sensible routes through it.

Go deep — the CNPE

The natural sequel. You now know the delivery tooling behind a quarter of the CNPE blueprint; what remains is the other four domains and, crucially, the hands. Start with the lab track, then the practice task bank — beginning with the GitOps set, where you will be fast — then a timed mock exam. Keep Know It Cold and the command reference open while you drill, and when a sync or a canary sticks, work it with the delivery triage guide rather than by guesswork.

Go wide, or go build

To broaden, pair CAPA with CGOA — the two are complementary rather than redundant, one examining the products and the other the specification behind them — and then take the administrator track (CKA, then CKS), which is what most platform roles actually screen for. To build, connect the four: have an Argo Events Sensor submit a Workflow that builds an image, have the Workflow bump a tag in the config repo, have Argo CD reconcile it, and have Argo Rollouts canary it behind an analysis gate. That chain is the entire exam, running, in one namespace — and it is a genuinely good delivery platform.