CAPA sample questions with answers

CAPA sample questions

Certified Argo Project Associate (CAPA), CNCF / The Linux Foundation.

1. Question 1

   Domain: Argo Workflows

   A CronWorkflow runs every minute. The Workflow Controller crashed at 12:05:55 and came back at 12:06:05, and the team argues about whether the 12:06:00 schedule should be recovered automatically.

   Which statement is correct about startingDeadlineSeconds here?

   1. Setting it above the elapsed grace period replays every schedule missed during the outage
   2. It has no effect on missed schedules and only bounds how long a workflow may run
   3. Setting it above the elapsed grace period lets the missed run start once, at 12:06:05
   4. It must be zero for recovery, because zero means no deadline
   Show the answer

   Answer: C. Setting it above the elapsed grace period lets the missed run start once, at 12:06:05

   startingDeadlineSeconds is a grace period past the last scheduled time during which a missed workflow will still run, and the documentation is explicit that only a single instance is executed as a result. It is unrelated to run duration, and the default of zero disables recovery rather than enabling it.

   Checked against: https://argo-workflows.readthedocs.io/en/latest/cron-workflows/

2. Question 2

   Domain: Argo Workflows

   A compatibility test must run the same template against four fixed image and tag combinations, and each iteration needs both values as separate parameters.

   How should the loop be written?

   1. Use withItems with plain strings such as "debian:9.1" and split them inside the container
   2. Use four separate steps, because withItems entries may only be single values
   3. Use withSequence with count: 4 and index into a ConfigMap by number
   4. Use withItems with a JSON object per entry and reference {{item.image}} and {{item.tag}}
   Show the answer

   Answer: D. Use withItems with a JSON object per entry and reference {{item.image}} and {{item.tag}}

   withItems accepts a JSON object per entry, and each element is addressed by key as {{item.image}} and {{item.tag}}, which keeps both values as first-class parameters. Packing values into one string pushes parsing into the container needlessly, and withItems is not limited to single values.

   Checked against: https://argo-workflows.readthedocs.io/en/latest/walk-through/loops/

3. Question 3

   Domain: Argo Workflows

   Several unrelated Workflows in a namespace deploy to the same staging environment, and only one may hold it at a time. The workflows are submitted by different teams and by a CronWorkflow.

   What is the simplest synchronization setting on each workflow spec?

   1. A semaphore whose ConfigMap key is set to the number of teams
   2. A workflow-level mutex with a shared name, which is equivalent to a semaphore of limit one
   3. A template-level parallelism of 1 on the entrypoint template, which limits concurrency across all workflows
   4. activeDeadlineSeconds, so that a stuck workflow releases the environment
   Show the answer

   Answer: B. A workflow-level mutex with a shared name, which is equivalent to a semaphore of limit one

   Workflows that reference the same mutex name serialise against one another, and the documentation notes a mutex is equivalent to a semaphore with a limit of one and needs no ConfigMap. parallelism restricts concurrent tasks within a single workflow only, and a deadline does not provide mutual exclusion.

   Checked against: https://argo-workflows.readthedocs.io/en/latest/synchronization/

4. Question 4

   Domain: Argo Workflows

   A nightly workflow writes several scratch artifacts plus one report that must survive indefinitely. The team sets spec.artifactGC.strategy to OnWorkflowDeletion.

   How should the report artifact be protected from garbage collection?

   1. Set artifactGC.strategy: Never on that individual output artifact to override the workflow default
   2. Remove the s3 key from the report so the collector cannot find it
   3. Set archive.none on the report, since only archived artifacts are collected
   4. Move the report to a second workflow, because the artifactGC strategy cannot be overridden for an individual artifact
   Show the answer

   Answer: A. Set artifactGC.strategy: Never on that individual output artifact to override the workflow default

   Artifact garbage collection strategy can be set at the workflow level and overridden on an individual artifact, and the documented example uses artifactGC.strategy: Never on the artifact that must be kept. Archiving and key naming do not affect whether an artifact is collected.

   Checked against: https://argo-workflows.readthedocs.io/en/latest/walk-through/artifacts/

5. Question 5

   Domain: Argo CD

   A legacy service is being handed to a team that does not use GitOps. Argo CD should stop managing it, but the running Deployment, Service and ConfigMap must keep serving traffic untouched.

   What is the correct action, and what distinguishes it from the alternative?

   1. Delete the Application with foreground propagation, which removes the Application object first and leaves all managed resources behind
   2. Move the Application to another project, which detaches the resources automatically
   3. Delete the Application non-cascading, which removes the finalizer and deletes only the Application, leaving resources running
   4. Remove the manifests from Git and sync with pruning, which unregisters the resources without deleting them
   Show the answer

   Answer: C. Delete the Application non-cascading, which removes the finalizer and deletes only the Application, leaving resources running

   A non-cascading delete, argocd app delete with --cascade=false or the Non-Cascading option in the UI, removes the finalizer and deletes only the Application object while all managed workloads keep running. Foreground and background propagation both delete the managed resources, pruning deletes them too, and changing project does not detach anything.

   Checked against: https://argo-cd.readthedocs.io/en/stable/user-guide/app_deletion/

6. Question 6

   Domain: Argo CD

   How does the argocd.argoproj.io/sync-wave annotation order resources?

   1. Resources are applied from the lowest wave number to the highest, with unannotated resources in wave 0
   2. Wave numbers must be positive and are applied in the order the files appear in the repository
   3. Waves are applied in alphabetical order of resource name within each kind
   4. Resources are applied from the highest wave number to the lowest, with unannotated resources applied last of all
   Show the answer

   Answer: A. Resources are applied from the lowest wave number to the highest, with unannotated resources in wave 0

   The wave value is an integer and Argo CD deploys from the lowest number to the highest, with hooks and resources defaulting to wave zero and negative waves allowed so work can run before everything else. Kind and name are only used as tie-breakers after phase and wave.

   Checked against: https://argo-cd.readthedocs.io/en/stable/user-guide/sync-waves/

7. Question 7

   Domain: Argo CD

   What makes Argo CD render an Application's source with Kustomize?

   1. The Application sets sourceType: kustomize explicitly, which is mandatory
   2. The destination namespace carries a kustomize annotation
   3. The repository is registered in argocd-cm as a Kustomize repository
   4. A kustomization.yaml file exists at the repoURL and path the Application points to
   Show the answer

   Answer: D. A kustomization.yaml file exists at the repoURL and path the Application points to

   If a kustomization.yaml file exists at the location given by repoURL and path, Argo CD renders the manifests with Kustomize; pointing path at an overlay directory is how overlays are selected. There is no mandatory source type field and no repository-level or namespace-level switch for this.

   Checked against: https://argo-cd.readthedocs.io/en/stable/user-guide/kustomize/

8. Question 8

   Domain: Argo Rollouts

   A blue-green release must run a smoke test against the preview stack and must not move production traffic if that test fails.

   Which analysis hook does that, and what happens on failure?

   1. An Experiment step, which is the only way to test a preview stack
   2. prePromotionAnalysis, which blocks the service selector switch and aborts the rollout if the run fails
   3. A background canary analysis, which is also available to blue-green rollouts
   4. postPromotionAnalysis, which runs before the selector switch and reverts it automatically if the run fails
   Show the answer

   Answer: B. prePromotionAnalysis, which blocks the service selector switch and aborts the rollout if the run fails

   prePromotionAnalysis runs after the new ReplicaSet becomes available but before traffic is switched, and its success or failure decides whether the Rollout switches traffic or aborts. postPromotionAnalysis runs after the cutover and, on failure, sends traffic back to the previous stable ReplicaSet, which is not the same as never switching.

   Checked against: https://argo-rollouts.readthedocs.io/en/stable/features/bluegreen/

9. Question 9

   Domain: Argo Rollouts

   A Deployment serving live production traffic is to become a Rollout. One engineer proposes deleting the Deployment and applying the Rollout in the same change; another proposes creating the Rollout first and only then removing the Deployment.

   Which is correct, and what is the cost of the safer option?

   1. Either is equally safe, because the Rollout adopts the Deployment's existing ReplicaSets on creation
   2. Create the Rollout first, but scale it to zero until the Deployment is deleted, so no extra pods run
   3. Delete the Deployment first, because two owners of the same selector cannot coexist and the overlap would corrupt both sets of ReplicaSets
   4. Create the Rollout alongside the Deployment first, accepting about twice the pods, because removing the Deployment first risks downtime
   Show the answer

   Answer: D. Create the Rollout alongside the Deployment first, accepting about twice the pods, because removing the Deployment first risks downtime

   The migration guide warns that a Rollout should run next to a Deployment already serving production traffic before that Deployment is deleted or scaled down, as not doing so may result in downtime, and notes that the cost is running twice as many pods during the migration. The Rollout does not adopt the Deployment's pods, and scaling it to zero would leave nothing to cut over to.

   Checked against: https://argo-rollouts.readthedocs.io/en/stable/migrating/

10. Question 10

    Domain: Argo Events

    Which implementations of the EventBus are available?

    1. Redis Streams, RabbitMQ and Kafka
    2. NATS, which is deprecated, JetStream, and Kafka
    3. Only JetStream, since the others were removed
    4. etcd, Kafka and Pulsar
    Show the answer

    Answer: B. NATS, which is deprecated, JetStream, and Kafka

    The EventBus connects event sources and sensors, and has three implementations: the original NATS Streaming, which is deprecated, JetStream, and Kafka. Redis, RabbitMQ via AMQP and Pulsar appear as event source types rather than as eventbus implementations.

    Checked against: https://argoproj.github.io/argo-events/concepts/eventbus/