Domain 1: Argo Workflows
- A Workflow is the actual running or completed instance of a pipeline: it has an entrypoint, a set of templates, and a status field showing its current phase.
- WorkflowTemplate is a namespace-scoped library of reusable template definitions; it is inert until a Workflow references it via templateRef or workflowTemplateRef.
- ClusterWorkflowTemplate is the cluster-scoped counterpart to WorkflowTemplate, letting any Workflow in any namespace reuse its templates; set clusterScope: true on templateRef to target one.
- CronWorkflow embeds a workflowSpec and a cron schedule; the controller actively creates a new Workflow object from that spec each time the schedule fires, unlike the passive WorkflowTemplate CRDs.
- templateRef points a task at a specific named template inside a WorkflowTemplate or ClusterWorkflowTemplate, while workflowTemplateRef on the Workflow itself adopts an entire template's spec and entrypoint with no local templates needed.
- The core template types are container (run a container), script (inline code with a shorthand result), resource (create, apply, patch, or delete a Kubernetes resource), suspend (pause for input or a duration), http, and plugin, plus the two invocator types dag and steps.
- A dag template defines tasks with explicit dependencies so independent tasks run in parallel automatically, while a steps template runs each inner list of steps in parallel but advances between outer step groups sequentially.
- Looping constructs include withItems for a static inline list, withParam for a dynamic list built from JSON at runtime, and withSequence for a generated numeric range.
- retryStrategy retries a failed step up to a configured limit with backoff, exit handlers (onExit) run regardless of overall success or failure, and synchronization via mutex or semaphore limits how many workflows or templates run concurrently.
- Artifacts (inputs and outputs) can be passed between steps and are backed by artifact repositories such as S3, GCS, Azure Blob, OSS, HTTP, or git, while parameters pass simple string values.
- ttlStrategy removes completed Workflow objects after a set time and Pod GC removes their pods, but the workflow archive can persist completed workflow records to a database for later lookup after that cleanup.
Domain 2: Argo CD
- An Argo CD Application requires a source (where manifests come from), a destination (where they are deployed), and a project (the AppProject it belongs to); syncPolicy is optional.
- spec.source.repoURL is the Git repository address, spec.source.path is the subdirectory within it to render, and spec.source.targetRevision pins a branch, tag, or commit; an omitted targetRevision tracks HEAD.
- spec.destination identifies the target cluster by server (its Kubernetes API URL, with https://kubernetes.default.svc meaning the local in-cluster API) or by a registered name, plus the namespace to deploy into.
- An AppProject scopes what an Application may do: allowed source repositories, allowed destination clusters and namespaces, and permitted resource kinds, providing multi-tenant guardrails.
- ApplicationSet uses generators (list, cluster, git, matrix, and others) to template and create many Applications from a single definition, which is the standard way to scale GitOps across many clusters or apps.
- Sync can be triggered manually via the CLI or UI, or applied automatically with syncPolicy.automated; prune (default false) deletes live resources removed from Git, and selfHeal reverts manual, out-of-band cluster changes back to the Git-defined state.
- The sync-wave annotation (argocd.argoproj.io/sync-wave) orders resources within a single sync so lower-numbered waves apply before higher-numbered ones.
- Resource hooks (PreSync, Sync, PostSync, SyncFail) run custom jobs at specific points in the sync lifecycle, with a hook-deletion policy controlling whether the hook resource is removed before creation, on success, or on failure.
- Sync status reflects whether live cluster state matches the desired state from Git (Synced or OutOfSync); health status reflects whether a resource is actually working (Healthy, Progressing, Degraded, and others), and the two are independent.
- The app-of-apps pattern uses one parent Application to manage a set of child Application manifests, letting a single Git commit bootstrap or update many applications at once.
- Argo CD renders manifests from Helm charts, Kustomize overlays, Jsonnet, plain directories, or a config management plugin, and ignoreDifferences suppresses specific fields (such as those mutated by other controllers) from being flagged as out-of-sync.
Domain 3: Argo Rollouts
- The Rollout custom resource (argoproj.io/v1alpha1) is a drop-in replacement for a Deployment: it keeps the same replicas, selector, and template fields but adds a strategy field for progressive delivery.
- A Rollout's strategy must be either canary or blueGreen; there is no built-in equivalent of a plain Deployment RollingUpdate or Recreate strategy.
- workloadRef lets a Rollout point at an existing Deployment and reuse its pod template directly, and scaleDown (never, onsuccess, or progressively) controls whether that original Deployment is scaled to zero once the Rollout takes over.
- Canary steps commonly include setWeight (percentage of traffic or replicas sent to the canary), pause (blocks indefinitely for a manual promote, or for a set duration if one is given), and setCanaryScale (decouples canary replica count from the traffic-weight percentage).
- An analysis step gates progression on real metrics: an AnalysisTemplate or cluster-scoped ClusterAnalysisTemplate defines the query, an AnalysisRun executes it, and the Rollout waits for a successful result before advancing, using providers such as Prometheus, Datadog, Wavefront, New Relic, Kayenta, Web, or Job.
- In the blueGreen strategy, the previewService points at the new ReplicaSet for testing before promotion, and the activeService is cut over to it only once the rollout is fully promoted.
- Precise traffic splitting during canary is delegated to a traffic management integration such as Istio, SMI, NGINX, ALB, Traefik, or the Gateway API; without one, weight is only approximated by the ratio of canary to stable replica counts.
- Because Rollout is a custom resource under argoproj.io rather than the built-in apps/v1, the native kubectl rollout subcommand does not recognize it; the kubectl argo rollouts plugin provides equivalents like get, promote, abort, and undo.
- revisionHistoryLimit bounds how many old ReplicaSets a Rollout retains for potential rollback, the same purpose it serves on a Deployment.
Domain 4: Argo Events
- Argo Events defines exactly three custom resources: EventSource, EventBus, and Sensor; a trigger is not its own CRD but a field within a Sensor's spec.triggers list.
- The event flow is EventSource, which ingests external activity and publishes normalized events to the EventBus, then Sensor, which subscribes to the EventBus, evaluates its dependencies and filters, and executes the matching trigger.
- The EventBus decouples producers from consumers, enabling fan-out to multiple Sensors and buffering; it is backed by NATS/JetStream by default, with Kafka also supported.
- Common EventSource types include webhook (a generic listening HTTP server), calendar (cron or interval schedules with optional timezone and exclusion dates), resource (Kubernetes object lifecycle changes via a native API watch, not polling), and queue-style sources like sqs, sns, and kafka.
- A Sensor's dependency pins down both a specific EventSource object and a named event within it; a single Sensor can depend on events from multiple EventSources, and one EventSource can serve multiple Sensors.
- Filters on a Sensor narrow which events actually fire a trigger, evaluating the event's data payload, its context metadata, time windows, or boolean expressions, and can be combined across dependencies with circuit-style logic.
- Trigger types executed by a Sensor include creating or patching a Kubernetes object, submitting an Argo Workflow, calling an HTTP endpoint, invoking an AWS Lambda, or publishing to Kafka, NATS, or Slack.
- EventSource, EventBus, and Sensor are all namespaced resources; a Sensor looks up its EventBus in its own namespace, conventionally one named default.
- Earlier Argo Events releases used a Gateway CRD as an intermediary between event producers and Sensors; that component was removed in favor of EventSources publishing directly onto the EventBus.
Certified Argo Project Associate (CAPA) exam tips
- Argo Workflows carries the heaviest weight (about a third of the exam): know cold the difference between a Workflow (a running instance), a WorkflowTemplate and ClusterWorkflowTemplate (namespace- vs cluster-scoped reusable templates), and a CronWorkflow (which actively spawns new Workflows on a schedule).
- For Argo CD, memorize the Application spec shape (source.repoURL/path/targetRevision, destination.server/namespace, project), the difference between sync status (Synced/OutOfSync) and health status (Healthy/Degraded/Progressing), and what prune and selfHeal each do.
- For Argo Rollouts, remember that strategy (canary or blueGreen) is the one field that turns a Rollout into progressive delivery, and that you manage it with the kubectl argo rollouts plugin, since the built-in kubectl rollout command does not recognize the Rollout CRD.
- For Argo Events, memorize the four-stage flow EventSource -> EventBus -> Sensor -> Trigger, and remember that a trigger lives inside a Sensor's spec rather than being its own custom resource.
- Across all four projects, track CRD scope carefully: ClusterWorkflowTemplate and ClusterAnalysisTemplate are cluster-scoped, while Workflow, WorkflowTemplate, CronWorkflow, Application, AppProject, Rollout, AnalysisTemplate, EventSource, EventBus, and Sensor are all namespace-scoped.
Study guide FAQ
What format and passing requirements does the CAPA exam have?
The CAPA is a multiple-choice, online proctored exam with 60 questions lasting about 90 minutes. It is scored on a scaled basis and the passing score is 750 out of 1000 (75%). There is no hands-on lab component, though questions frequently present YAML manifests or CLI output to interpret.
What are the four Argo projects covered by the exam?
CAPA covers Argo Workflows (Kubernetes-native workflow orchestration for pipelines and job-style automation), Argo CD (declarative GitOps continuous delivery), Argo Rollouts (progressive delivery with canary and blue-green strategies), and Argo Events (event-driven automation built on EventSources, an EventBus, and Sensors). Each is a separate open source project under the Argo umbrella, so questions largely test them independently rather than in combination.
What prerequisite knowledge do I need before attempting CAPA?
You should be comfortable with core Kubernetes objects and concepts (Pods, Deployments, Services, namespaces, RBAC, custom resources) and basic kubectl usage, since every Argo project is delivered as Kubernetes CRDs and controllers. Hands-on practice installing and using each of the four projects, even briefly, will help far more than reading alone.
How does CAPA differ from the CKA or CKAD exams?
CKA and CKAD test general Kubernetes administration and application development skills through a hands-on, live-cluster performance format. CAPA is knowledge-based multiple-choice and is scoped narrowly to the Argo project ecosystem (Workflows, CD, Rollouts, Events) rather than core Kubernetes, so it assumes Kubernetes fundamentals as background rather than testing them directly.
How should I prepare for CAPA?
Study each project in rough proportion to its exam weight: Argo Workflows and Argo CD each make up close to a third of the exam, while Argo Rollouts and Argo Events each make up a smaller, roughly equal share. Read each project's official documentation, deploy a local cluster to try the CRDs firsthand (a Workflow with a DAG, an Application with automated sync, a canary Rollout, an event-triggered Sensor), and practice reading YAML manifests since the exam leans heavily on spec-field recognition.