Certifications · CAPA · Practice Questions

CAPA Practice Questions

This page is the CAPA question bank — twenty-three single-best-answer questions, split across the four official domains in roughly the same proportion the CNCF's blueprint weights them, each with every option worked through in the answer key rather than a bare correct letter. It sits between two other pages on this ladder rung: read CAPA — the exam first if you haven't, since the questions below assume you already know what a Workflow template, an Application's sync status, a Rollout's canary steps and an EventSource's dependency block actually are. Once this bank stops surprising you, move on to the timed, full-length CAPA Mock Exam · Set 1 and Set 2. Every question here is original content written against the published CAPA competencies — none of it is drawn from, or claims to reproduce, the real proctored exam.

How this bank works

☺ Like you're 10: Cover the four answers with your hand, guess first, then look — and if a question fools you twice, that's the one to actually go study.

Every question below has a stem (the scenario or the exact thing being asked), four options, and exactly one key. The other three are not padding — each is built from a real misconception someone genuinely holds: a distinction from the wrong domain, a rule stated one qualifier too strongly, a mechanism that sounds plausible but doesn't exist, or a true fact that simply doesn't answer the question that was asked. That is how CNCF-style multiple-choice items are actually constructed, and it is why "I recognised a true statement" is not the same skill as "I found the one that answers this stem" — see the CAPA blueprint for how the real exam is built the same way.

The four piles, sized like the blueprint

Twenty-three questions split across four domains can't hit 36/34/18/12 exactly, but they land close, and in the same rank order — Workflows and Argo CD are still the two piles worth almost three-quarters of the bank between them:

Argo Workflows — questions 1–8 (36% of the blueprint)

☺ Like you're 10: This pile is about the to-do-list robot — the one that runs jobs in order, or several at once, and passes files between them.

1. What does spec.entrypoint identify in a Workflow manifest?

   1. The container image used for every step in the workflow
   2. The name of the template, among those listed under spec.templates, where execution begins
   3. The Kubernetes namespace the workflow's pods are scheduled into
   4. The REST endpoint the workflow-controller exposes for that workflow
   Show answer & explanation

   Answer: B. entrypoint names one template from spec.templates as the starting point — commonly a dag or steps template that then composes the rest. Nothing in a Workflow sets one image for every step (A); the namespace comes from metadata.namespace, not the spec's execution logic (C); and there is no such per-workflow REST endpoint (D) — the argo-server exposes one API for the whole install.

2. The CAPA curriculum splits Argo Workflows template types into "definitions" (things that actually do work) and "invocators" (things that compose other templates). Which grouping is correct?

   1. dag and steps are definitions; container and script are invocators
   2. container, script, resource and suspend are definitions; dag and steps are invocators
   3. Only dag is an invocator — steps is a definition, since it just lists steps in order
   4. resource is an invocator, because it can create objects that call other templates
   Show answer & explanation

   Answer: B. container and script run something; resource creates or patches a Kubernetes object; suspend pauses. None of the four compose other templates, which is exactly what makes them definitions. dag and steps exist purely to sequence and parallelise the definitions above — that's the invocator role. Option A has the two groups reversed; C wrongly demotes steps, which composes tasks exactly like dag does; D invents a capability resource doesn't have.

3. A telemetry pipeline is defined as a DAG:

   templates:
     - name: pipeline
       dag:
         tasks:
           - name: extract
             template: extract
           - name: transform-spans
             template: cruncher
             dependencies: [extract]
           - name: transform-logs
             template: cruncher
             dependencies: [extract]
           - name: load
             template: loader
             dependencies: [transform-spans, transform-logs]

   Which task or tasks run only after both transform-spans and transform-logs have completed?

   1. extract
   2. transform-spans and transform-logs, run a second time
   3. load, and only load
   4. All four tasks run in parallel, since no explicit ordering is set at the top level
   Show answer & explanation

   Answer: C. load lists both transform-spans and transform-logs in its dependencies, so the controller withholds it until both finish — a fan-in. extract (A) runs first, not after. There's no mechanism that re-runs a task (B). And the DAG is precisely how you do set ordering — the two transform-* tasks fan out in parallel because they share one dependency, not because ordering is absent (D).

4. A workflow step needs to pass a 400 MB Parquet file it produced to the next step in the DAG. Which mechanism is built for this?

   1. outputs.parameters, since parameters can hold any string value
   2. An environment variable set on the producing step's container
   3. outputs.artifacts, backed by the artifact repository configured for the cluster (commonly S3, GCS or MinIO)
   4. A ConfigMap created by the step and mounted into the next one
   Show answer & explanation

   Answer: C. Workflows moves two kinds of data: small strings as parameters, and files — of any real size — as artifacts, written to and read from a configured repository via outputs.artifacts / inputs.artifacts. Parameters (A) aren't meant for file payloads. An env var (B) doesn't survive past the pod. A ConfigMap (D) has a hard size ceiling in the low megabytes and isn't how Workflows models this at all.

5. Team Nebula wants one reusable library of workflow templates that every namespace on the cluster can reference with templateRef, without copying the YAML into each namespace. Which resource is built for that?

   1. A WorkflowTemplate, created once in each namespace that needs it
   2. A ClusterWorkflowTemplate
   3. A CronWorkflow, since it can be referenced from anywhere
   4. A ConfigMap holding the template YAML, applied cluster-wide
   Show answer & explanation

   Answer: B. WorkflowTemplate (A) is namespaced by design — exactly the duplication the team wants to avoid. ClusterWorkflowTemplate is the cluster-scoped sibling, definable once and referenced from any namespace. CronWorkflow (C) is about scheduling, not scope. Argo Workflows has no mechanism that resolves a templateRef against a plain ConfigMap (D).

6. Which resource lets Argo Workflows submit a new Workflow automatically on a recurring schedule, natively, without an external scheduler?

   1. A WorkflowTemplate with a schedule field
   2. A CronWorkflow
   3. A Sensor subscribed to a calendar-based EventSource
   4. A Workflow whose first template is suspend
   Show answer & explanation

   Answer: B. CronWorkflow is the Workflows-native scheduling resource — it holds a cron expression and a workflow template, and submits on schedule. WorkflowTemplate (A) has no schedule field. C describes a real, working pattern, but it's Argo Events' answer to the same problem, not Workflows' own mechanism — a classic wrong-project distractor. suspend (D) pauses a running workflow for a human or a timer; it doesn't trigger a new one.

7. A workflow needs to run the same cruncher template once per file in a list that is only known at runtime — produced as the previous step's output. Which mechanism creates one task per item dynamically, instead of hardcoding a fixed number of parallel tasks in the DAG?

   1. Manually duplicating the task definition for each file the team expects to see
   2. withParam, fed by a JSON list the previous step wrote to its output
   3. Setting retryStrategy.limit high enough to cover every file
   4. Inserting a suspend step before each expected file
   Show answer & explanation

   Answer: B. withParam (or the static list form, withItems) fans a task out once per element of a list, and the list can come straight from a prior step's output — this is the map-reduce shape the curriculum means by "Run Data Processing Jobs." A (fixed duplication) breaks the moment the file count changes at runtime. retryStrategy (C) governs retries after failure, not fan-out. suspend (D) pauses; it doesn't multiply tasks.

8. Which two components form the operational core of an Argo Workflows install: one that reconciles Workflow objects into running pods, and one that exposes the API and web UI?

   1. kube-scheduler and kubelet
   2. The workflow-controller and the argo-server
   3. The repo-server and the application-controller
   4. The EventBus and the Sensor
   Show answer & explanation

   Answer: B. The workflow-controller watches Workflow objects and creates the pods that run them; argo-server is the API and UI layer. A names plain Kubernetes scheduling components, not Argo ones. C is real, but it's Argo CD's pair of components, not Workflows' — and D is Argo Events' pair. Knowing which project owns which named component is worth marks across all four domains.

Argo CD — questions 9–16 (34% of the blueprint)

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

9. An Argo CD Application's spec is built from three core top-level blocks. Which set is correct?

   1. source, destination, syncPolicy
   2. repoURL, targetRevision, path
   3. project, server, namespace
   4. helm, kustomize, directory
   Show answer & explanation

   Answer: A. source (where the manifests live), destination (where they're applied) and syncPolicy (how syncing behaves) are the three top-level blocks. B lists real fields — but they sit inside source, one level too deep to be the answer. C mixes a real top-level field (project) with fields that actually live inside destination. D names the three alternative renderer options that live inside source, not the blocks themselves.

10. An Application's sync status reads Synced and its health status reads Degraded. What does that combination actually mean?

    1. Argo CD failed to apply the manifests it read from Git
    2. The live manifests match Git exactly, but the resulting Kubernetes resources — say, a Deployment stuck in CrashLoopBackOff — aren't actually healthy
    3. Git and the live cluster have diverged, and a sync is required to fix it
    4. Health checks are disabled for this Application
    Show answer & explanation

    Answer: B. Sync status and health status answer two different questions — "does live match Git?" and "is the live thing actually well?" — and they're independent. Synced rules out A and C outright: applying succeeded and nothing has drifted. D is a fabrication; Degraded is exactly what health checks report when something is unwell.

11. Below is (part of) an Application pointed at a Helm chart:

    spec:
      source:
        repoURL: https://github.com/kubestronaut/platform-config.git
        targetRevision: main
        path: charts/mission-control-api
        helm:
          releaseName: mission-control-api
          valueFiles: [values-prod.yaml]
          parameters:
            - name: image.tag
              value: "2.1.0"

    Which single field, if changed, updates only the container image tag this Application deploys — without changing which chart, branch or values file it uses?

    1. spec.source.targetRevision
    2. The value of the image.tag entry under spec.source.helm.parameters
    3. spec.destination.namespace
    4. spec.source.path
    Show answer & explanation

    Answer: B. helm.parameters is exactly the mechanism the "Configure Argo CD with Helm and Kustomize" competency is pointing at — a Helm --set-equivalent applied by the repo-server at render time. targetRevision (A) would change the Git ref the whole chart is read from. destination.namespace (C) changes where it's deployed, not what. source.path (D) changes which chart entirely.

12. An Application's syncPolicy.automated has prune: true and selfHeal: false. An engineer manually deletes a ConfigMap that is still declared in Git. What happens, by default, until someone intervenes?

    1. Argo CD immediately recreates the ConfigMap on its own, because prune also governs missing resources
    2. The Application is marked OutOfSync, but the ConfigMap is not automatically recreated until a sync is manually triggered or selfHeal is turned on
    3. Argo CD deletes the entire Application, since a required resource is missing
    4. Nothing happens at all — the missing ConfigMap is never flagged
    Show answer & explanation

    Answer: B. prune only deletes live resources that are no longer declared in Git — it doesn't recreate resources removed from the live cluster. Reacting automatically to that kind of live drift is exactly what selfHeal does; without it, Argo CD detects and reports the drift (OutOfSync) but waits for a human or the next sync. A misattributes selfHeal's job to prune. C and D are both fabrications — nothing here deletes the Application, and the drift is reported, not ignored.

13. Which Argo CD mechanism runs a database-migration Job exactly once, guaranteed to complete before the rest of an Application's resources are applied?

    1. Setting argocd.argoproj.io/sync-wave: "-1" on every resource except the Job
    2. A PreSync resource hook on the Job
    3. An ignoreDifferences entry scoped to the Job
    4. Setting syncPolicy.automated.selfHeal: true on the Application
    Show answer & explanation

    Answer: B. Resource hooks (PreSync, Sync, PostSync, SyncFail) are exactly this — PreSync runs before the main sync applies anything else. A tries to force the same outcome sideways through sync waves on every other resource, which is backwards and fragile compared to hooking the Job directly. ignoreDifferences (C) is about diffing, not ordering. selfHeal (D) is about drift correction and has nothing to do with sequencing a one-off Job.

14. A platform team wants one Application per environment (dev, staging, prod) for the same service, generated automatically from a list of environments — not three hand-maintained, near-identical Application manifests. Which Argo CD resource is built for this?

    1. AppProject
    2. ApplicationSet
    3. A single Application with three destination blocks
    4. ignoreDifferences with a wildcard jsonPointers entry
    Show answer & explanation

    Answer: B. ApplicationSet generates many Application objects from one template plus a generator — a list generator over three environments is a textbook use. AppProject (A) governs tenancy and permissions, not generation. An Application (C) has exactly one destination, not several. D is unrelated to generating Applications at all.

15. Which Argo CD resource restricts which Git repositories, destination clusters/namespaces, and resource kinds a group of Applications is allowed to use?

    1. ApplicationSet
    2. AppProject
    3. A sync window
    4. The Argo CD RBAC ConfigMap
    Show answer & explanation

    Answer: B. AppProject is the tenancy boundary — allowed source repos, allowed destinations, allowed resource kinds — that Applications assigned to it must stay inside. ApplicationSet (A) generates Applications; it doesn't fence them. A sync window (C) restricts when syncing happens, not what an Application may touch. The RBAC ConfigMap (D) is real, but it governs which users can do what in the UI/API — a true statement about the wrong layer of the problem.

16. An Application manages a Deployment that also has a HorizontalPodAutoscaler attached, and carries this block:

      ignoreDifferences:
        - group: apps
          kind: Deployment
          jsonPointers: ["/spec/replicas"]

    Without this block, what problem does the team actually hit?

    1. The HPA is unable to scale the Deployment at all until the block is added
    2. Argo CD keeps reporting the Application OutOfSync on replica count and, if selfHeal is on, keeps reverting the HPA's scaling decisions back to the count declared in Git
    3. Kubernetes rejects the Deployment outright, since two controllers can't manage the same field
    4. The Deployment's container image stops updating on new commits
    Show answer & explanation

    Answer: B. ignoreDifferences tells Argo CD's diff engine to stop treating a field as drift — here, /spec/replicas, which the HPA legitimately owns at runtime. Without it, every HPA-driven scale reads as drift: constant OutOfSync noise at minimum, and with selfHeal on, Argo CD actively fights the HPA back down to the Git-declared count. The HPA itself still functions mechanically (A is false); Kubernetes has no such rejection rule (C); and this block has nothing to do with the image tag (D).

Argo Rollouts — questions 17–20 (18% of the blueprint)

☺ Like you're 10: This pile is about 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.

17. What can a Rollout do that a plain Kubernetes Deployment fundamentally cannot?

    1. Define a pod template with container images and resource limits
    2. Shift traffic by a controlled percentage, gate progression on a live metrics check, and pause mid-release for a human or a timer
    3. Run more than one replica
    4. Be deployed and managed through a GitOps tool like Argo CD
    Show answer & explanation

    Answer: B. That's the entire reason the CRD exists: fine-grained progressive delivery via steps — setWeight, pause, analysis — that a Deployment's all-or-nothing rolling update has no concept of. A, C and D are all things a plain Deployment already does perfectly well; none of them is the gap Rollouts fills.

18. A canary step in a Rollout reads:

          steps:
            - setWeight: 10
            - pause: { duration: 5m }
            - analysis:
                templates:
                  - templateName: success-rate
            - setWeight: 50
            - pause: {}

    At the moment the Rollout reaches the analysis step, what object gets created?

    1. A new AnalysisTemplate, cloned from success-rate
    2. An AnalysisRun, which evaluates the referenced template's metrics live and reports its own status back to the Rollout
    3. A plain Kubernetes Job that runs the Prometheus query directly
    4. Nothing new — the Rollout controller queries Prometheus itself and stores the result inline in its own status
    Show answer & explanation

    Answer: B. The AnalysisTemplate is the reusable definition; reaching an analysis step instantiates it as a fresh AnalysisRun, a separate object with its own live status that the Rollout watches to decide whether to proceed or abort. Nothing is cloned (A) — the template stays as-is and is referenced repeatedly. There's no intermediate Job (C); the AnalysisRun controller queries the provider (here, Prometheus) directly. And D is simply inaccurate — the whole point of the AnalysisRun object is that the result is tracked externally, not folded silently into the Rollout.

19. Using the same canary steps shown above, which step is the one that stops the rollout from advancing until a human explicitly promotes it?

    1. setWeight: 50
    2. pause: { duration: 5m }
    3. The analysis step
    4. pause: {}, with no duration set
    Show answer & explanation

    Answer: D. A pause with a duration (B) resumes on its own once the timer elapses. An empty pause: {} has no timer at all — the Rollout parks there until someone runs a manual promote. setWeight (A) just sets a traffic split; it doesn't block anything by itself. The analysis step (C) gates on live metrics and can abort the rollout, but it isn't what forces a manual hold — that's specifically the un-timed pause.

20. A canary Rollout's AnalysisRun fails its successCondition and the rollout aborts. What happens to traffic and to the Rollout's status?

    1. Traffic stays split at the last setWeight percentage while the Rollout marks itself Progressing and waits to retry
    2. Traffic shifts entirely back to the stable ReplicaSet, and the Rollout is deliberately left Degraded so a human investigates, rather than being silently retried
    3. The canary Pods are left serving 100% of traffic until someone manually rolls back
    4. Kubernetes automatically deletes the Rollout object
    Show answer & explanation

    Answer: B. An aborted canary reverts traffic to stable immediately, but the Rollout is intentionally parked Degraded rather than being quietly retried — a failed analysis is meant to page a human, not disappear. A has the status wrong (it wouldn't say Progressing after an abort). C describes roughly the opposite of what actually happens. D is a fabrication — nothing here deletes the object. One more detail worth knowing alongside this: real traffic-percentage shifting itself needs a traffic router — an ingress controller, service mesh, SMI or the Gateway API — or the weight is only approximated by pod counts.

Argo Events — questions 21–23 (12% of the blueprint)

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

21. Put these three Argo Events components in the order an event actually flows through them, from the outside world to a triggered action:

    1. Sensor → EventBus → EventSource
    2. EventSource → EventBus → Sensor
    3. EventBus → Sensor → EventSource
    4. EventSource → Sensor → EventBus
    Show answer & explanation

    Answer: B. An EventSource listens to the outside world and publishes onto the EventBus; a Sensor subscribes to named dependencies on that bus and fires a trigger once its conditions are met. The other three orderings each put the transport (EventBus) or the subscriber (Sensor) somewhere the message hasn't reached yet.

22. Given this EventSource/Sensor pair:

    apiVersion: argoproj.io/v1alpha1
    kind: EventSource
    metadata:
      name: git-webhook
    spec:
      webhook:
        push:
          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
      triggers:
        - template:
            name: run-pipeline
            argoWorkflow:
              operation: submit

    For the Sensor's dependency to actually fire when this EventSource receives a POST to /push, what has to match between the two manifests?

    1. The metadata.name of the EventSource and the Sensor objects must be identical
    2. The Sensor's dependencies[].eventName must match the key used under the EventSource's event-type block — here, push
    3. Both objects must be deployed into the argocd namespace
    4. The Sensor's triggers[].template.name must match the EventSource's endpoint value
    Show answer & explanation

    Answer: B. The Sensor names the EventSource by eventSourceName and the specific event by eventName, which must equal the key the EventSource published under — push, in this case. Object names (A) can differ freely as long as eventSourceName points correctly. There's no argocd-namespace requirement (C) — that's an Argo CD convention, not an Events one, and a wrong-project distractor. The trigger's own template.name (D) is just a label for the trigger; it has no relationship to the webhook's endpoint path.

23. How does Argo Events' fundamental behavior differ from Argo CD's, even though both projects watch for change?

    1. Argo Events only works with Git repositories, while Argo CD can watch any object store
    2. Argo Events creates Kubernetes objects on demand when a discrete event occurs; Argo CD continuously reconciles state whether or not anything happened at all
    3. Argo Events has been deprecated in favor of Argo CD's built-in webhook support
    4. Argo CD is event-driven and Argo Events is the one that reconciles continuously
    Show answer & explanation

    Answer: B. Argo Events is reactive — nothing happens until an event arrives, and then it acts once. Argo CD is the opposite: it keeps re-checking desired-versus-live state on its own reconciliation loop regardless of whether anything actually changed. A is false in both directions. C is a fabrication — the two remain separate, actively maintained projects with different jobs. D takes the real distinction and swaps the two projects, which is exactly the kind of reversed-pairing trap worth watching for on the real exam.

Turning a wrong answer into a fact

☺ Like you're 10: The score isn't the point. What matters is why you got one wrong — because "I never knew that" and "I knew it but misread the question" need completely different fixes.

Finishing the bank and noting a percentage teaches you almost nothing on its own. When you miss one, decide honestly which of two things happened. If you genuinely didn't know the fact, that's a content gap — go reread the matching section of CAPA — the exam, and don't move on until you can restate it in your own words. If you knew the material but picked wrong anyway, that's almost always a misread stem or a distractor that got you on speed rather than knowledge — reread the exact wording of the question you missed before you touch the next one. Either way, questions you miss twice on a later pass are the ones actually worth writing down.

If you want a rough, self-graded pass/fail signal: the Linux Foundation's published cut score for its multiple-choice exams, CAPA included, is 75%. Scoring at or above that here, cold, across all 23, is a reasonable — though entirely unofficial — readiness signal before you book the timed mock exam.

Check your answers

1. 23 questions — 8 Argo Workflows, 8 Argo CD, 4 Argo Rollouts, 3 Argo Events, tracking the blueprint's 36/34/18/12 split in rank order if not in exact percentage.
2. Argo Workflows (tied with Argo CD at 8 each) — because Workflows is the single largest domain on the real blueprint at 36%, ahead of Argo CD's 34%, even though Argo CD is the more famous project.
3. Any two of: prune (deletes live resources removed from Git) vs. selfHeal (reverts live changes made outside Git); sync waves (order resources within one sync) vs. resource hooks (run something at a lifecycle point like PreSync); ApplicationSet (generates many Applications) vs. AppProject (fences what a group of Applications may do).
4. An AnalysisTemplate is the reusable definition — the metric, provider and successCondition. An AnalysisRun is the live instance created when a Rollout actually reaches an analysis step, carrying its own result that promotes or aborts the release.
5. False. A pause with a duration resumes on its own; an empty pause: {} has no timer and waits for a manual promote.
6. Argo Events — it's event-driven and acts once per discrete event, in contrast to Argo CD, which keeps re-checking desired-versus-live state on a continuous loop regardless of whether anything happened. Reversing that pairing is exactly the kind of trap the exam sets.
7. Reread the exact wording of the question you missed before moving on — most misses on material you actually know come from a misread stem or a distractor that won on speed, not from a real content gap, and you can only tell the difference by rereading immediately.