Free CAPA practice test: 30 questions with answers

spec.entrypoint names the template where a run begins, so it must match a template name in spec.templates. Labels, arguments and the service account do not decide which template starts, and cluster-admin rights are not a fix for a missing entrypoint.

Each container-based node in a workflow runs as a pod created for that step. A Deployment is meant for long-running services, a CronJob is a separate scheduled resource, and a ConfigMap cannot run code.

Passing output artifacts between steps needs an artifact repository such as an S3-compatible bucket, so without one the step cannot save its output and the workflow fails. The other options describe storage behaviour that Argo Workflows does not use for artifacts.

Output artifacts can feed later steps as input artifacts, and that transfer uses an object-store artifact repository configured for the controller. Artifacts are not kept in the workflow status, and the API server does not carry file contents, so the other two statements are wrong.

A WorkflowTemplate holds one shared definition that many Workflows can reference, so an update applies to every caller. Copying spreads changes across manifests, Secrets are meant for sensitive values rather than workflow logic, and a CronWorkflow controls scheduling rather than sharing steps.

activeDeadlineSeconds is the workflow-level time limit that makes the controller terminate a run that takes too long. ttlStrategy only cleans up after completion, parallelism limits concurrency, and podGC controls when finished pods are deleted, so none of them enforces a run-time limit.

A dag task lists the tasks it depends on in its dependencies field, and it starts only when all of them have succeeded. A single dependency would let package start before unit-test is done, while withItems creates fan-out copies rather than ordering, so both of those are wrong.

In a steps template each group runs after the previous group completes, with the steps inside one group running in parallel. A dag template has no fixed groups and starts each task as soon as the tasks it depends on have finished; the other options invent limits that do not exist.

GitOps keeps the desired state in Git, and Argo CD continuously compares the live cluster against it. Building images, scheduling pods and storing secrets are handled by other tools or components, so those options are not the GitOps model.

With automated sync off, Argo CD only reports drift and waits for an operator to sync. It never reverts or deletes resources on its own in that mode, and it does not write changes back into Git.

spec.destination identifies the target cluster and namespace for the Application's resources. spec.source points at the Git or Helm input, spec.project names the governing AppProject, and spec.syncPolicy controls how syncs run.

An AppProject restricts which repositories and destinations its Applications may use, which is exactly this guardrail. A ClusterRole grants Kubernetes permissions rather than project limits, and an ApplicationSet generates Applications without restricting them.

The prune setting inside syncPolicy.automated lets automated sync delete live resources that were removed from Git. selfHeal reverts manual edits instead, CreateNamespace only creates namespaces, and a PreSync hook runs a task before the sync.

selfHeal makes automated sync correct drift caused by manual changes in the cluster, restoring the Git state. Pod restarts, image builds and sync retries are different mechanisms and are not what selfHeal does.

Sync waves are set with the argocd.argoproj.io/sync-wave annotation, and Argo CD applies lower-numbered waves before higher ones. File names do not control order, and SyncFail hooks only run when a sync fails.

A PreSync hook runs before the main resources of a sync are applied, so the migration finishes first. PostSync runs after the rollout, Prune=false only protects a resource from deletion, and managed-by is not a hook mechanism.

A Rollout is the Argo Rollouts workload that takes the place of a Deployment and adds the canary and blue-green strategies with analysis. A Service only routes traffic, while a StatefulSet and an HPA serve different purposes.

A canary strategy takes a list of steps, where setWeight moves traffic to the new version and pause holds it for observation. Blue-green switches traffic as a whole, and recreate and rolling update are Deployment strategies rather than Rollout ones.

Promotion points the active Service at the new ReplicaSet, so production moves over in one step. Weighted splitting belongs to canary releases, and blue-green keeps the old ReplicaSet around for a period rather than deleting it at once.

An AnalysisTemplate describes the metrics and the success or failure conditions that a Rollout checks before moving on. Traffic routing, image pinning and node placement are handled by other configuration, not by the template.

When an AnalysisRun fails its failure condition, the Rollout aborts and the stable version takes the traffic again. Analysis results are not informational only, and a failed run is never treated as a success or retried silently.

Without a traffic router, the Service balances across all ready pods, so scaling the canary to a share of the total pods gives an approximate split. Weights on Services, Ingress edits and moving pods to other namespaces are not how the replica-based approach works.

A pause step without a duration waits indefinitely until it is promoted, for example with kubectl argo rollouts promote. A timed pause resumes by itself, and setWeight or analysis steps do not wait for a person.

A Sensor declares event dependencies and runs its triggers, such as creating a Workflow, once the dependencies are satisfied. Receiving external events is the job of an EventSource, and the messaging layer is the EventBus.

A webhook EventSource exposes an HTTP endpoint that turns incoming requests into events for the rest of the system. A Sensor consumes events rather than receiving HTTP requests, and the EventBus only carries events between components.

EventSources bring external events in and publish them to the EventBus, which carries them to Sensors in the same namespace. Sensors do not store workflow outputs or manage the bus pods, so the other two statements are wrong.

An EventSource ingests the bucket notifications as events, and a Sensor with a trigger creates the Workflow when they arrive. A Sensor does not ingest storage events, AnalysisTemplates measure metrics, and ApplicationSets generate Applications rather than Workflows.

The EventBus is the messaging layer that connects EventSources and Sensors in a namespace, and its default setup is typically NATS. Credentials are referenced from Secrets rather than stored by the bus, and triggers, not the bus, decide what a Sensor creates.

A trigger's conditions expression combines dependency names, and using && requires every named dependency to be present before the trigger fires. The || operator fires on either event, and separate Sensors or withItems do not combine two dependencies into one run.

Argo Events uses the CloudEvents specification to describe events in a common, vendor-neutral envelope. The other specifications cover tracing, container images and JSON validation, which are unrelated to the event format.