Cheat sheet & self-check

Pick an answer to see if you got it, and why.

1. Q1. What's the key difference between push-based CD and GitOps (pull-based)?

   1. APull is always faster
   2. BIn GitOps an agent inside the cluster pulls desired state from Git and reconciles continuously; CI no longer needs cluster admin credentials
   3. CPush doesn't use Git
   4. DGitOps doesn't use CI
   Show answer

   B. Pull keeps cluster credentials inside the cluster and corrects drift continuously, not only when a pipeline runs.

   From lesson 01 · GitOps principles & Argo CD architecture

2. Q2. Someone runs kubectl edit on a Deployment that Argo CD manages. What happens?

   1. ANothing, ever
   2. BArgo CD marks the app OutOfSync; with selfHeal enabled it reverts the change to match Git
   3. CGit is updated automatically
   4. DArgo CD deletes the Deployment
   Show answer

   B. Git is the source of truth. Drift is detected, and with self-heal it's corrected automatically.

   From lesson 01 · GitOps principles & Argo CD architecture

3. Q3. Which Argo CD component renders Helm charts and Kustomize overlays into plain manifests?

   1. Aargocd-server
   2. Bargocd-repo-server
   3. Cargocd-redis
   4. Dargocd-dex-server
   Show answer

   B. The repo-server clones the repository and produces the manifests the controller compares with the live cluster.

   From lesson 01 · GitOps principles & Argo CD architecture

4. Q4. What does `prune: true` in an automated sync policy do?

   1. ADeletes old Git branches
   2. BDeletes cluster resources that the app manages but that were removed from Git
   3. CRemoves unused images
   4. DCleans the repo-server cache
   Show answer

   B. Without prune, resources deleted from Git stay in the cluster (the app shows OutOfSync). With prune, Argo CD deletes them.

   From lesson 02 · Installing Argo CD & the first app

5. Q5. What does `selfHeal: true` add to automated sync?

   1. ARestarts crashed pods
   2. BRe-syncs when the live state drifts from Git even though Git didn't change (e.g. after a manual kubectl edit)
   3. CHeals etcd
   4. DRetries failed image pulls
   Show answer

   B. Automated sync alone reacts to new commits; self-heal also reverts manual changes.

   From lesson 02 · Installing Argo CD & the first app

6. Q6. With automated sync enabled, what's the GitOps way to roll back a bad release?

   1. Aargocd app rollback only
   2. Bgit revert the commit, so Git again describes the good state and Argo CD syncs it
   3. Ckubectl rollout undo
   4. DDelete the Application
   Show answer

   B. Rolling back in the cluster without changing Git gets undone by the next sync. (Argo CD's rollback command is refused while automated sync is on.)

   From lesson 02 · Installing Argo CD & the first app

7. Q7. What is the App-of-Apps pattern?

   1. AOne huge Application containing all YAML
   2. BA root Application whose source directory contains Application manifests, so Argo CD creates and manages the child Applications from Git
   3. CA Helm chart of Argo CD
   4. DA plugin
   Show answer

   B. Adding a child is a Git commit; the root app syncs it into existence. One manual apply bootstraps everything.

   From lesson 03 · App-of-Apps pattern

8. Q8. Why put apps in AppProjects instead of 'default'?

   1. APerformance
   2. BProjects restrict source repos, destination clusters/namespaces and resource kinds, and scope RBAC, so a team's app can't deploy cluster-wide objects or into another team's namespace
   3. CRequired by Kubernetes
   4. DTo enable the UI
   Show answer

   B. The default project allows everything. Projects are Argo CD's multi-tenancy guard rails.

   From lesson 03 · App-of-Apps pattern

9. Q9. You delete a child Application that has the resources finalizer. What happens?

   1. ANothing in the cluster
   2. BArgo CD deletes the Kubernetes resources the Application managed (cascade), then the Application
   3. CGit is deleted
   4. DOnly pods restart
   Show answer

   B. With the finalizer, deletion cascades. Without it, the resources are left running but unmanaged.

   From lesson 03 · App-of-Apps pattern

10. Q10. How does Argo CD apply a Helm chart?

    1. AIt runs helm install, and releases show in helm list
    2. BIt renders the chart (like helm template) and applies the manifests itself, so Argo CD, not Helm, tracks the resources
    3. CIt converts charts to Kustomize
    4. DIt can't use Helm
    Show answer

    B. Argo CD owns the lifecycle. Helm hooks are mapped to Argo CD hooks, and `helm list` won't show the app.

    From lesson 04 · Helm & Kustomize with Argo CD

11. Q11. What's a clean way to keep dev, staging and prod differences with Kustomize?

    1. ACopy the whole folder three times
    2. BA shared base plus one overlay per environment with only the differences (replicas, image tag, resources), each overlay targeted by its own Application
    3. CBranches per environment only
    4. DEnvironment variables in Argo CD
    Show answer

    B. Overlays keep the common part in one place, and the diff between environments is small and reviewable.

    From lesson 04 · Helm & Kustomize with Argo CD

12. Q12. How do you promote a new image from staging to prod in GitOps?

    1. Akubectl set image in prod
    2. BChange the image tag in the prod overlay/values in Git (a reviewed commit or PR); Argo CD syncs it
    3. CRestart Argo CD
    4. DCopy the staging cluster
    Show answer

    B. Promotion is a Git change, so it's reviewed, recorded and revertible.

    From lesson 04 · Helm & Kustomize with Argo CD

13. Q13. What does an ApplicationSet do?

    1. AGroups apps in the UI only
    2. BGenerates Applications from a template, using generators (clusters, Git folders/files, lists, SCM, pull requests, combinations)
    3. CReplaces AppProjects
    4. DSyncs faster
    Show answer

    B. One ApplicationSet can create hundreds of Applications, and it adds or removes them as clusters or folders come and go.

    From lesson 05 · Multi-cluster management

14. Q14. You label a newly registered cluster env=prod. With a cluster generator selecting env=prod, what happens?

    1. ANothing until you create apps by hand
    2. BThe ApplicationSet generates Applications for the new cluster automatically, so it gets the same add-ons as the other prod clusters
    3. CAll clusters resync
    4. DThe cluster is deleted
    Show answer

    B. Labels become the interface: the fleet's shape is described by data, not by hand-made Applications.

    From lesson 05 · Multi-cluster management

15. Q15. Hub-and-spoke (one Argo CD managing many clusters) vs Argo CD in every cluster: a key trade-off?

    1. ANone
    2. BHub: one pane of glass but the hub holds credentials to every cluster and is a shared dependency; per-cluster: isolation and edge autonomy but many instances to operate
    3. CPer-cluster can't use Git
    4. DHub can't use ApplicationSets
    Show answer

    B. Many fleets mix both: a hub for central clusters and local Argo CD (or pull agents) for disconnected edge sites.

    From lesson 05 · Multi-cluster management

16. Q16. Your app needs a database migration Job to finish before the new Deployment rolls out. How?

    1. ADeploy them in two commits
    2. BMake the Job a PreSync hook (or put it in an earlier sync wave), so Argo CD waits for it to succeed before applying the Deployment
    3. CUse a CronJob
    4. DIncrease replicas
    Show answer

    B. PreSync hooks run before the main sync, and a failed hook stops the sync, so the new version never starts against an unmigrated database.

    From lesson 06 · Sync policies, hooks & waves

17. Q17. An HPA scales a Deployment to 7 replicas, but Git says 3, and Argo CD keeps resetting it. Fix?

    1. ADisable the HPA
    2. BRemove replicas from the manifest or add ignoreDifferences for /spec/replicas (with RespectIgnoreDifferences=true), so Argo CD stops fighting the HPA
    3. CSet replicas to 7 in Git
    4. DTurn off Argo CD
    Show answer

    B. When another controller owns a field, tell Argo CD to ignore it. Otherwise self-heal and the HPA fight forever.

    From lesson 06 · Sync policies, hooks & waves

18. Q18. How does Argo CD order resources inside a sync phase?

    1. ARandomly
    2. BBy sync wave (lowest first), then by kind (e.g. Namespaces and CRDs before the objects that use them), then by name
    3. CAlphabetically only
    4. DBy file size
    Show answer

    B. Waves give you explicit control on top of the built-in kind ordering.

    From lesson 06 · Sync policies, hooks & waves

19. Q19. How should teams log in to a production Argo CD?

    1. AEveryone shares the admin password
    2. BSSO through the corporate IdP (OIDC), with IdP groups mapped to Argo CD roles in argocd-rbac-cm, and the local admin disabled
    3. Ckubectl only
    4. DAnonymous access
    Show answer

    B. SSO gives individual identity and offboarding; group-based RBAC keeps permissions manageable.

    From lesson 07 · Production patterns

20. Q20. A commit removed a folder, and prune deleted a namespace with a database PVC. What prevents this next time?

    1. ANothing can
    2. BPrune=false / Delete=false on critical resources (PVCs, namespaces with data), reviews on deletions, and staged rollouts before prod
    3. CDisabling Git
    4. DTurning off health checks
    Show answer

    B. Prune is correct behaviour given the commit. Guard critical objects explicitly, and make deletions visible in review.

    From lesson 07 · Production patterns

21. Q21. What's the GitOps-friendly way to handle secrets?

    1. ACommit them in plain YAML to a private repo
    2. BCommit encrypted secrets (Sealed Secrets, SOPS) or references to an external store (External Secrets Operator), never plain values
    3. CPut them in the Application spec
    4. DEmail them
    Show answer

    B. Git history is permanent and widely read. Store only encrypted data or references.

    From lesson 07 · Production patterns