Argo Rollouts fundamentals: CAPA practice questions
Argo Rollouts adds progressive delivery to Kubernetes. Progressive delivery releases a new version gradually, exposing it to part of the traffic, checking that it behaves and then widening the exposure, usually with automated analysis deciding whether to promote or roll back. A standard Deployment can only do a rolling update, so Argo Rollouts introduces its own workload resource.
By Ibrahim Yesilay · Published · Updated
Independent community practice, not affiliated with or endorsed by CNCF or The Linux Foundation.
What Argo Rollouts fundamentals covers in CAPA
Argo Rollouts adds progressive delivery to Kubernetes. Progressive delivery releases a new version gradually, exposing it to part of the traffic, checking that it behaves and then widening the exposure, usually with automated analysis deciding whether to promote or roll back. A standard Deployment can only do a rolling update, so Argo Rollouts introduces its own workload resource.
A Rollout is a custom resource that is mostly compatible with a Deployment: it has replicas, a selector and a Pod template, plus a strategy block for blue-green or canary, the only two strategies it supports. Converting a Deployment usually means changing apiVersion and kind and adding the strategy. Alternatively, a Rollout can reference an existing Deployment with workloadRef and take its Pod template from there; the scaleDown setting of workloadRef decides whether the Deployment is never scaled down, scaled down once the Rollout is healthy, or scaled down progressively as the Rollout scales up.
The Argo Rollouts controller watches Rollout resources only. It ignores ordinary Deployments, so it can be installed in a cluster that also deploys applications in other ways. For each revision the controller manages a ReplicaSet, labelled with a pod template hash, and those ReplicaSets should not be edited by other tools. Services and, optionally, an ingress controller or service mesh route traffic to the right ReplicaSet, and the AnalysisTemplate and AnalysisRun resources connect a release to metrics. Analysis is optional: a Rollout can be paused and promoted by hand.
Most operations go through the kubectl argo rollouts plugin. get rollout with --watch shows the revisions, steps and status; promote moves a paused Rollout to the next step, and with --full skips the remaining steps and analysis; abort stops an update and returns traffic to the stable version; retry restarts an aborted Rollout; undo rolls back to an earlier revision, and set image changes the image. An integrated dashboard can show the same information in a browser.
A Rollout reports its own status. When an update is aborted, the Rollout is marked Degraded even though the stable version is still serving, and it stays Degraded until its desired Pod template is changed back to the stable version.
Key points
- A Rollout replaces a Deployment and supports only the blue-green and canary strategies.
- workloadRef lets a Rollout reuse the Pod template of an existing Deployment.
- The controller ignores plain Deployments, so it can share a cluster with other delivery tools.
- kubectl argo rollouts promote, abort, retry and undo drive a Rollout by hand.
Three sample questions
10 CAPA questions on Argo Rollouts fundamentals, 10 with explanations. How practice works
Question 1
- A.
kubectl argo rollouts get rollout rollout-name - B.
kubectl argo rollouts status rollout-name --watch - C.
kubectl get rollout rollout-name - D.
kubectl describe rollout rollout-name
Correct answer: A
kubectl argo rollouts get rollout NAME prints rollout metadata plus a tree of child resources (revisions, ReplicaSets, pods, experiments, analysis runs); -w keeps updating it as the rollout progresses. Why the other options are wrong. "kubectl argo rollouts status rollout-name --watch": status watches until the rollout finishes and returns success if it is healthy, it is not the tree view. "kubectl get rollout rollout-name": plain kubectl get prints the generic resource listing, without the plugin's tree view. "kubectl describe rollout rollout-name": kubectl describe shows generic Kubernetes resource details, without the plugin's tree view.Sources: Argo Rollouts docs: Kubectl Plugin, Argo Rollouts docs: kubectl argo rollouts get rollout, Argo Rollouts docs: kubectl argo rollouts status
Question 2
- A.A permanent test environment in a separate namespace where new features are deployed and exercised before production
- B.A way to run parallel ReplicaSets with different configurations for comparison
- C.A rollback strategy that restores the previous ReplicaSet automatically when a Rollout is aborted
- D.A type of analysis template that defines the metrics and success conditions for a canary
Correct answer: B
Sources: Argo Rollouts docs: Experiments, Argo Rollouts docs: Analysis
Question 3
- A.To manage workflow execution, scheduling and retrying DAG and step templates on Kubernetes
- B.To roll back failed deployments automatically for any workload type, including StatefulSets and DaemonSets
- C.To automate Kubernetes cluster updates, including node pool upgrades and control-plane version changes
- D.To provide progressive delivery strategies like blue-green and canary deployments
Correct answer: D
Sources: Argo Rollouts docs: Overview, Argo Rollouts docs: Concepts
Practice this topic
Focus mode keeps every question on Argo Rollouts fundamentals until you leave it. 10 free guest answers, then a free account; no credit card.
Or open CAPA practice across all topics.
Sources
The explanation above was checked against these official documents.
- Argo Rollouts docs: Concepts (checked 2026-10-28)
- Argo Rollouts docs: Architecture (checked 2026-10-28)
- Argo Rollouts docs: Migrating to Rollouts (checked 2026-10-28)
- Argo Rollouts docs: Kubectl plugin (checked 2026-10-28)
- Argo Rollouts docs: kubectl argo rollouts promote (checked 2026-10-28)
- Argo Rollouts docs: kubectl argo rollouts abort (checked 2026-10-28)
- Argo Rollouts docs: Getting started (checked 2026-10-28)