Skip to content

Argo

← Back to all decks

65 cards — 🟢 12 easy | 🟡 26 medium | 🔴 12 hard

🟢 Easy (12)

1. How to check the status of a rollout?

Show answer `kubectl argo rollouts status SOME-APP`

Under the hood: returns the phase (Progressing, Paused, Degraded, Healthy) plus replica counts and error messages if any.

Remember: phases are Progressing, Paused, Degraded, Healthy. Paused = waiting for manual promote or analysis result.

2. True or False? You need to install ArgoCD in order to use Argo Rollouts

Show answer False. Quite common misconception today but both cab be used independency even though they work nicely together.

Remember: ArgoCD = continuous delivery from Git. Argo Rollouts = progressive delivery strategies. They pair well but are independent.

Fun fact: the Argo project also includes Argo Workflows (DAG-based job orchestration) and Argo Events (event-driven triggers).

3. How to list rollouts?

Show answer `kubectl argo rollouts list rollouts`

Fun fact: Argo Rollouts extends Kubernetes with a Rollout CRD replacing Deployments for canary, blue-green, and progressive delivery strategies.

Remember: Argo Rollouts extends K8s with a Rollout CRD. Use kubectl argo rollouts (plugin) to manage them, not plain kubectl.

4. What is Argo Rollouts?

Show answer A controller for Kubernetes to perform application deployments using different strategies like Blue/Green deployments, Canary deployments, etc.

In addition, it supports A/B tests, automatic rollbacks and integrated metric analysis.

Remember: Rollouts replaces Deployments for advanced strategies. Think 'Deployment on steroids' — canary, blue-green, analysis, auto-rollback.

Gotcha: Argo Rollouts is a separate install from ArgoCD. They complement each other but work independently.

5. True or False? ArgoCD supports Kubernetes YAML files but not other manifests formats like Helm Charts and Kustomize

Show answer False. It supports Kubernetes YAML files as well as Helm Charts and Kustomize.

See also: ArgoCD also supports Jsonnet, directory-of-manifests, and custom config management plugins for proprietary templating.

Gotcha: ArgoCD renders Helm charts server-side. helm ls won't show ArgoCD-managed releases. Use argocd app get instead.

6. What is the "App of Apps Patterns"?

Show answer A solution from Argo community in regards to managing multiple similar applications.

Basically a pattern where you have root application that consists of other child applications.

So instead of creating multiple separate applications, you have the root application pointing to a repository with additional applications.

Remember: App of Apps = 'one parent Application that manages child Applications.' Bootstrap an entire cluster with one ArgoCD Application pointing to a repo of Application manifests.

7. How to list the rollouts of a given application?

Show answer `kubectl argo rollouts get rollout SOME-APP`

Under the hood: shows a tree-style visualization with revision history, active/preview ReplicaSets, pod status, and current step progress.

Remember: Argo Rollouts replaces Deployments with a Rollout CRD that supports canary, blue-green, and progressive delivery with automated analysis and rollback.

Remember: an ArgoCD Application CRD defines: source (Git repo + path + revision), destination (cluster + namespace), and sync policy. It's the fundamental GitOps unit.

8. How to list all the clusters ArgoCD manage?

Show answer `argocd cluster list`

Under the hood: the in-cluster (where ArgoCD runs) always appears as default. Each added cluster is stored as a Secret with connection details and TLS certificates.

Remember: ArgoCD follows the GitOps principle: Git is the single source of truth. All cluster changes go through Git commits, providing an audit trail and easy rollback via git revert.

9. True or False? An ingress is considered healthy if status.loadBalancer.ingress list includes at least one value

Show answer True. An ingress resource is healthy when status.loadBalancer.ingress has at least one entry, meaning the cloud provider has assigned an IP or hostname to serve traffic.

Remember: ArgoCD follows the GitOps principle: Git is the single source of truth. All cluster changes go through Git commits, providing an audit trail and easy rollback via git revert.

10. How do you list all applications managed by Argo CD?

Show answer `argocd app list`

See also: argocd app list -o json | jq for scripting. Filter by project with -p PROJECT.

Under the hood: queries Application CRDs in the argocd namespace.

Remember: an ArgoCD Application CRD defines: source (Git repo + path + revision), destination (cluster + namespace), and sync policy. It's the fundamental GitOps unit.

11. What is Argo CD and how does it enable GitOps for Kubernetes?

Show answer [ArgoCD](https://argo-cd.readthedocs.io/en/stable): "Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes."

As to why Argo CD, they provide the following explanation: "Application definitions, configurations, and environments should be declarative and version controlled. Application deployment and lifecycle management should be automated, auditable, and easy to understand."

Remember: ArgoCD = 'Git is the truth, cluster follows.' It continuously reconciles cluster state with a Git repo.

Name origin: from Greek mythology — the Argo was Jason's ship. ArgoCD 'navigates' your deployments to their destination.

12. True or False? ArgoCD sync period is 3 hours

Show answer False. ArgoCD sync period is 3 minutes as of today (and not hours).

Under the hood: configurable via timeout.reconciliation in argocd-cm ConfigMap (seconds). Set up Git webhooks for instant sync on push.

Remember: default sync = 3 minutes. For faster sync, configure Git webhooks to trigger ArgoCD immediately on push.

Gotcha: lowering the sync period increases API server load. Webhooks are the scalable solution.

🟡 Medium (26)

1. How to rollout a new version (with new container tag)?

Show answer `kubectl argo rollouts set image SOME-APP web-app=some/registry/and/image:v2.0`

Under the hood: patches the Rollout spec with the new image tag, triggering the configured strategy (canary steps, blue-green switch, or analysis run).

Gotcha: the image name must match exactly what is in the Rollout spec, including the full registry path.

Remember: Argo Rollouts replaces Deployments with a Rollout CRD that supports canary, blue-green, and progressive delivery with automated analysis and rollback.

2. What happens when you rollout a new version of your app with argo rollouts?

Show answer - Argo Rollouts creates a new replicaset (that is the new app version)
- Old version is still alive
- ArgoCD marks the app as out-of-sync

Remember: Argo Rollouts replaces Deployments with a Rollout CRD that supports canary, blue-green, and progressive delivery with automated analysis and rollback.

Remember: an ArgoCD Application CRD defines: source (Git repo + path + revision), destination (cluster + namespace), and sync policy. It's the fundamental GitOps unit.

3. True or False? If you have multiple Kubernetes clusters you want to manage sync applications to with ArgoCD then, you must have ArgoCD installed on each one of them

Show answer False, it can be deployed on one of them. ArgoCD is able to manage external clusters on which it doesn't run.

Remember: an ArgoCD Application CRD defines: source (Git repo + path + revision), destination (cluster + namespace), and sync policy. It's the fundamental GitOps unit.

Remember: ArgoCD sync states: Synced (cluster matches Git), OutOfSync (drift detected), Unknown (cannot determine). Use argocd app sync APP_NAME to force reconciliation.

4. How to add an additional (external) cluster for ArgoCD to manage?

Show answer `argocd cluster add CLUSTER_ADDRESS/NAME`

Under the hood: stores cluster credentials as Kubernetes Secrets in the argocd namespace. The target cluster must be reachable from the ArgoCD controller pod.

Gotcha: the cluster context must exist in your local kubeconfig before running this command.

Remember: ArgoCD follows the GitOps principle: Git is the single source of truth. All cluster changes go through Git commits, providing an audit trail and easy rollback via git revert.

5. You deployed a new application in a namespace called "yay" but when running kubectl get ns yay you see there is no such namespace. What happened?

Show answer Deploying applications in non-existing namespaces doesn't create the namespace. For that you have to explicitly mark "Auto-create namespace".

To fix it, you can simply run `kubectl create namespace NAMESPACE_NAME` but it's better of course to have it stored in Git rather than running kubectl commands.

Remember: an ArgoCD Application CRD defines: source (Git repo + path + revision), destination (cluster + namespace), and sync policy. It's the fundamental GitOps unit.

6. True or False? A Deployment considered to be healthy if the Pods are running

Show answer Not exactly. A Deployment (as well as StatefulSet, ReplicaSet and DaemonSet) is considered healthy if the desired state equals the actual/current state (this includes the number of replicas).

Remember: ArgoCD follows the GitOps principle: Git is the single source of truth. All cluster changes go through Git commits, providing an audit trail and easy rollback via git revert.

7. Scott, an engineer in your team, executes manually some smoke tests and monitors rollouts every time a new version is deployed. This way, if there is an issue he detects, he performs a rollback. What better approach you might suggest him to take?

Show answer Shift towards fully automated rollbacks. Argo Rollouts supports multiple metric providers (Datadog, NewRelic, etc.) so you can use data and metrics for automating the rollbacks based on different conditions

Remember: Argo Rollouts replaces Deployments with a Rollout CRD that supports canary, blue-green, and progressive delivery with automated analysis and rollback.

Remember: an ArgoCD Application CRD defines: source (Git repo + path + revision), destination (cluster + namespace), and sync policy. It's the fundamental GitOps unit.

8. How the main resource in ArgoCD called?

Show answer Application — the core custom resource in ArgoCD that defines the source repository, target cluster, and sync policy for a Kubernetes deployment. Each Application tracks one repo-to-cluster mapping and shows real-time sync status.

Remember: ArgoCD follows the GitOps principle: Git is the single source of truth. All cluster changes go through Git commits, providing an audit trail and easy rollback via git revert.

9. Describe the purpose of the following section in an Application YAML file

Show answer This section defines with which Kubernetes cluster the app in the tracked Git repository should be synced with.

Remember: an ArgoCD Application CRD defines: source (Git repo + path + revision), destination (cluster + namespace), and sync policy. It's the fundamental GitOps unit.

Remember: ArgoCD Application YAML has spec.source (where to get manifests) and spec.destination (where to deploy). Each section maps to a Git repo and a Kubernetes cluster/namespace.

10. Explain self-heal in regards to ArgoCD

Show answer Self-heal is the process of correcting the cluster state based on the desired state, when someone makes manual changes to the cluster.

Remember: self-heal = 'undo manual kubectl edits.' ArgoCD reverts cluster state to match Git. Enable via spec.syncPolicy.automated.selfHeal: true.

Gotcha: self-heal can be surprising — if someone runs kubectl scale to handle an emergency, ArgoCD will revert it. Communicate this to your team.

11. Explain the concept of "Analysis" in regards to Argo Rollouts

Show answer Analysis is a resource deployed alongside Rollout resources and defines the conditions and metrics thresholds for performing a rollback

Remember: AnalysisRun = automated canary judgment. Define metrics + thresholds. Pass = promote, Fail = rollback. No human in the loop.

Example: query Prometheus for error rate < 1%. If it fails, the canary auto-rollbacks. Connect to Datadog, NewRelic, or any metrics provider.

12. What CRD would you use if you have multiple applications and you would like to group them together logically?

Show answer AppProject. It defines which repos, destinations, and cluster resources a group of Applications can use — essentially RBAC boundaries for ArgoCD apps.

Remember: AppProject = RBAC boundary. Restrict which repos, clusters, and namespaces a team's Applications can access.

13. What are some possible health statuses for an ArgoCD application?

Show answer * Healthy
* Missing: resource doesn't exist in the cluster
* Suspended: resource is paused
* Progressing: resources isn't healthy but will become healthy or has the chance to become healthy
* Degraded: resource isn't healthy
* Unknown: it's not known what's the app health

Remember: HMSPDU — Healthy, Missing, Suspended, Progressing, Degraded, Unknown. Mnemonic: 'How Many Services Per Deployment Unit?'

14. Create a new application with the following properties:

Show answer ```\nargocd app create some-app \\n--project \\n--repo https://fake.repo.address \\n--path ./app_path \\n--dest-namespace default \\n--dest-server my.kubernetes.cluster\n```

Remember: an ArgoCD Application CRD defines: source (Git repo + path + revision), destination (cluster + namespace), and sync policy. It's the fundamental GitOps unit.

Remember: argocd app create requires: --repo (Git URL), --path (directory in repo), --dest-server (cluster), --dest-namespace. Use YAML manifests for reproducibility over CLI flags.

15. What can you tell about the health of custom Kubernetes resources?

Show answer The health of custom Kubernetes resources is defined by writing Lua scripts.

You find such list of scripts here: https://github.com/argoproj/argo-cd/tree/master/resource_customizations

Remember: ArgoCD follows the GitOps principle: Git is the single source of truth. All cluster changes go through Git commits, providing an audit trail and easy rollback via git revert.

16. What are the advantages in using GitOps approach/repository?

Show answer * Your whole configuration is one place, defined as code so it's completely transparent, adjustable for changes and easily reproducible
* Everyone go through the same interface hence you have more people experiencing and testing the code, even if not intentionally
* Engineers can use it for testing, development, ... there is no more running manual commands and hoping to reach the same status as in the cluster/cloud.
* Single source of truth: you know that your GitOps is the repo from which changes can be done to the cluster. So even if someone tries to manually override it, it won't work.

17. Ella, an engineer in your team, claims ArgoCD benefit is that it's an extension Kubernetes, it's part of the cluster. Sarah, also an engineer in your team, claims it's not a real benefit as Jenkins can be also deployed in the cluster hence being part of it. What's your take?

Show answer Ella is right, ArgoCD is an extension of the cluster, that is very different from simply being deployed in the cluster as other CI/CD systems like Jenkins. ArgoCD uses existing k8s resources like K8s controllers (for monitoring and state differences) and etcd for storing data.

Remember: ArgoCD follows the GitOps principle: Git is the single source of truth. All cluster changes go through Git commits, providing an audit trail and easy rollback via git revert.

18. Print detailed information on the app called "some-app"

Show answer `argocd app get some-app`

Under the hood: shows sync status, health, source repo, target cluster/namespace, and live status of every managed resource (Deployments, Services, ConfigMaps).

Remember: an ArgoCD Application CRD defines: source (Git repo + path + revision), destination (cluster + namespace), and sync policy. It's the fundamental GitOps unit.

19. How to manually promote to new app version?

Show answer `kubectl argo rollouts promote SOME-APP`

Under the hood: advances a paused canary or blue-green rollout to the next step. Use --full to skip all remaining steps and complete immediately.

Gotcha: promoting a rollout that is not currently paused has no effect.

Remember: promote = 'advance to next step.' Use --full to skip all remaining canary steps and go straight to 100%.

20. What will be the result of setting timeout.reconciliation: 0s?

Show answer sync functionality will be disabled.

Gotcha: with reconciliation disabled, ArgoCD never detects drift automatically. You must trigger syncs manually via UI or CLI. Consider a short interval (30s) instead of disabling entirely.

Gotcha: 0s disables automatic sync detection entirely. Use this only if you rely exclusively on Git webhooks for sync triggers.

21. True or False? When ArgoCD tracks Helm chart the chart is no longer an Helm application and it's a ArgoCD app

Show answer True. Trying to execute commands like `helm ls` will fail because helm metadata doesn't exist anymore and the application is tracked as ArgoCD app.

Gotcha: once ArgoCD manages a Helm chart, helm ls won't show it. ArgoCD renders the chart and manages the raw manifests. No Helm release metadata is stored.

22. Describe an example of workflow where ArgoCD is used

Show answer 1. A developer submitted change to an application repository
2. Jenkins pipeline is triggered to run CI on the change
3. If the Jenkins Pipeline completed successfully, build an image out of the new code
4. Push to image to a registry
5. Update K8S manifest file(s) in a separate app config repository
6. ArgoCD tracks changes in the app config repository. Since there was a change in the repository, it will apply the changes from the repo

Remember: typical GitOps workflow: developer pushes code -> CI builds image -> CI updates manifest repo -> ArgoCD detects change -> ArgoCD syncs cluster. Clean separation of concerns.

Remember: ArgoCD Application YAML has spec.source (where to get manifests) and spec.destination (where to deploy). Each section maps to a Git repo and a Kubernetes cluster/namespace.

23. Can you provide some use cases for using "App of Apps Patterns"?

Show answer * Cluster Preparation: You would like to deploy multiple applications at once to bootstrap a Kubernetes cluster

* Multiple environments: If deploying many versions of the same application, but with minor changes. For example, several test deployments to test different features

* Multiple clusters: when the same application needs to be deployed across multiple K8s clusters connected to ArgoCD

Remember: App of Apps = 'one parent Application that manages child Applications.' Bootstrap an entire cluster with one ArgoCD Application pointing to a repo of Application manifests.

24. What support is provided in ArgoCD for Helm?

Show answer ArgoCD is able to track packaged Helm chart in a sense where it will monitor for new versions.

Gotcha: ArgoCD renders Helm charts server-side. helm ls won't show ArgoCD-managed releases. Use argocd app get instead.

25. How do you monitor a rollout?

Show answer `kubectl argo rollouts get rollout SOME-APP --watch`

Under the hood: shows a tree-style visualization with revision history, active/preview ReplicaSets, pod status, and current step progress.

Remember: Argo Rollouts replaces Deployments with a Rollout CRD that supports canary, blue-green, and progressive delivery with automated analysis and rollback.

26. Explain what is an "Application" in regards to ArgoCD

Show answer It's a custom resource definitions which responsible for the deployment and synchronization of application resources to a Kubernetes cluster.

Remember: Application CRD = source (Git repo + path) + destination (cluster + namespace) + sync policy. It's the fundamental unit of ArgoCD.

🔴 Hard (12)

1. How cluster disaster recovery becomes easier with ArgoCD?

Show answer Imagine you have a cluster in the cloud, in one of the regions. Something happens to that cluster and it's either crashes or simply no longer operational.

If you have all your cluster configuration in a GitOps repository, ArgoCD can be pointed to that repository while be configured to use a new cluster you've set up and apply that configuration so your cluster is again up and running with the same status as o

Remember: GitOps = 'cluster is cattle, Git is the pet.' Lose a cluster? Point ArgoCD at the same Git repo + new cluster = restored.

2. You've three clusters - dev, staging and prod. Whenever you update the application GitOps repo, all three clusters are being updated. What's the problem with that and how to deal with it?

Show answer You don't usually want to go and update all of your clusters at once, especially when some for testing and development purposes and some for actual production usage.

There are multiple ways to deal with it:

1. Branch driven: Have branches for your GitOps repo where you push first to development, do some testing, merge it then to staging and if everything works fine in staging, you merge it to production.

2. Use overlays and Kustomize to control the context of where your changes synced based on the CI process/pipeline used.

3. Is it possible to change default sync period of ArgoCD?

Show answer Yes, it is possible by adding the following to the argocd-cm (ConfigMap):

```\ndata:\n timeout.reconciliation: 300s\n```

The value can be any number of seconds you would like to set.

Remember: ArgoCD sync states: Synced (cluster matches Git), OutOfSync (drift detected), Unknown (cannot determine). Use argocd app sync APP_NAME to force reconciliation.

4. What is auto-pruning in container registries and why is it important?

Show answer If enabled, auto-pruning will remove resources when files or content is removed from a tracked Git repository.

If disabled, ArgoCD will not remove anything, even when content or files are removed.

Gotcha: without auto-prune, deleting a manifest from Git leaves the resource orphaned in the cluster. Enable spec.syncPolicy.automated.prune: true to clean up automatically.

5. Nate, one of the engineers in your organization, asked whether it's possible if ArgoCD didn't sync for changes done manually to the cluster. What would be your answer?

Show answer The answer is yes, it's possible. You can configure ArgoCD to sync to desired state when changes done manually and instead do something like sending alerts.

Remember: ArgoCD sync states: Synced (cluster matches Git), OutOfSync (drift detected), Unknown (cannot determine). Use argocd app sync APP_NAME to force reconciliation.

6. Explain manual syncs vs. automatic syncs

Show answer Automatic syncs means that once ArgoCD detected a change or a new version of your app in Git, it will apply the changes so the current/actual state can be equal to desired state.

With manual syncs, ArgoCD will identify there is a difference, but will do nothing to correct it.

Remember: auto-sync = 'GitOps autopilot.' Manual sync = 'GitOps with a seatbelt.' Most teams start manual and graduate to auto after building confidence.

7. There have been a lot of CI/CD systems before ArgoCD (Jenkins, Teamcity, CircleCI, etc.) What added value has ArgoCD brought?

Show answer Simply said, ArgoCD is CD, not CI. We still need CI systems. Secondly, ArgoCD is running on Kubernetes, it's part of its ecosystem, as opposed to some other CI/CD systems. Finally, ArgoCD was built specifically for Kubernetes, not other platforms and systems.

Easier to explain the need for ArgoCD by direct comparison to another system that can do CD. Let's use Jenkins for this.

With Jenkins, you need make sure to install k8s related tools and set access for commands like kubectl.\

8. How ArgoCD makes access management in the cluster easier?

Show answer Instead of creating Kubernetes resources, you can use Git to manage who is allowed to push code, to review it, merge it, etc - either human users or 3rd party systems and services. There is no need to use ClusterRole or User resources in Kubernetes hence the management of access is much more simplified.

Remember: ArgoCD follows the GitOps principle: Git is the single source of truth. All cluster changes go through Git commits, providing an audit trail and easy rollback via git revert.

9. Describe shortly what ArgoCD does every sync period

Show answer 1. Gathers list of all the apps to sync (those that are marked with "auto-sync")
2. Gets Git state for each repository
3. Performs comparison between the repository Git state and the Kubernetes cluster state
1. If states are different, the application marked as "out-of-sync" and further action might be taken (based on the configuration)
2. If states are equal, the application marked as "synced"

Remember: ArgoCD sync states: Synced (cluster matches Git), OutOfSync (drift detected), Unknown (cannot determine). Use argocd app sync APP_NAME to force reconciliation.

Remember: ArgoCD Application YAML has spec.source (where to get manifests) and spec.destination (where to deploy). Each section maps to a Git repo and a Kubernetes cluster/namespace.

10. What "GitOps Repository" means in regards to ArgoCD?

Show answer It's the repository that holds app configuration, the one updated most of the time by CI/CD processes or DevOps, SRE engineers. In regards to ArgoCD it's the repository ArgoCD tracks for changes and apply them when they are detected.

Remember: GitOps repo = 'desired state repo.' CI builds images and updates this repo. ArgoCD watches it and syncs the cluster. Separation of concerns: code repo vs. config repo.

11. Sorina, one of the engineers in your team, made manual changes to the cluster that override some of the configuration in a repo traced by ArgoCD. What will happen?

Show answer Once Sorina made the modifications, ArgoCD will detect the state diverged and will sync the changes from the GitOps repository, overwriting the manual changes done by Sorina.

Remember: an ArgoCD Application CRD defines: source (Git repo + path + revision), destination (cluster + namespace), and sync policy. It's the fundamental GitOps unit.

12. Explain the following configuration

Show answer It's an Analysis resource that fetches response status from Prometheus (monitoring instance). If it's more than 0.90 the rollout will continue, if it's less than 0.90 a rollback will be performed meaning the canary deployment failed.

Remember: ArgoCD follows the GitOps principle: Git is the single source of truth. All cluster changes go through Git commits, providing an audit trail and easy rollback via git revert.