Cheat sheet & self-check

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

1. Q1. What does the External Secrets Operator store in Git?

   1. AEncrypted secret values
   2. BOnly a reference (which key in which secret manager, and where to put it); the value stays in the secret manager
   3. CPlain-text secrets
   4. DNothing at all
   Show answer

   B. ExternalSecret objects are safe to commit. The operator fetches values with its own identity and creates Kubernetes Secrets.

   From lesson 04 · Secrets in GitOps

2. Q2. What's a key limitation of Sealed Secrets?

   1. AIt needs AWS
   2. BA sealed secret is encrypted for one cluster's controller key; rotating that key or moving clusters needs re-sealing or key backup/restore
   3. CIt can't be used with Argo CD
   4. DIt stores plain text
   Show answer

   B. Simple and self-contained, but tied to the controller's key pair. Back up the sealing keys.

   From lesson 04 · Secrets in GitOps

3. Q3. Rotating a database password is easiest with which approach?

   1. APlain Secret in Git
   2. BExternal Secrets with a secret manager that rotates it; the operator refreshes the Kubernetes Secret on its interval
   3. CSealed Secrets
   4. DSOPS
   Show answer

   B. With a reference-based approach nothing in Git changes when the value rotates.

   From lesson 04 · Secrets in GitOps

4. Q4. What is drift in GitOps?

   1. AA slow network
   2. BAny difference between the live cluster and the desired state in Git, e.g. from kubectl edit or a controller changing a field
   3. CA Git merge conflict
   4. DA new release
   Show answer

   B. Drift is detected by comparing live objects with rendered Git manifests.

   From lesson 05 · Drift, rollback and recovery

5. Q5. Why must pruning be enabled with care?

   1. AIt's slow
   2. BWith prune, deleting a manifest from Git deletes the object in the cluster, including anything like a PVC or namespace if it was managed there
   3. CIt disables self-heal
   4. DIt breaks Helm
   Show answer

   B. Prune keeps the cluster clean, but protect stateful objects (annotations to prevent pruning/deletion) and review deletions in PRs.

   From lesson 05 · Drift, rollback and recovery

6. Q6. A field keeps showing OutOfSync because an HPA changes replicas. Fix?

   1. ADisable the HPA
   2. BDon't set replicas in Git for HPA-managed workloads, or tell the agent to ignore that field (ignoreDifferences)
   3. CTurn off Argo CD
   4. DPin replicas in Git to 3
   Show answer

   B. Two controllers must not own the same field. Let the HPA own replicas.

   From lesson 05 · Drift, rollback and recovery

7. Q7. What's the core structural difference between Flux and Argo CD?

   1. AOnly one supports Helm
   2. BFlux is a set of independent controllers configured through CRDs (no central server/UI by default); Argo CD is an application-centric server with a UI, API and its own RBAC
   3. CArgo CD is push-based
   4. DFlux doesn't use Git
   Show answer

   B. Both are pull-based GitOps agents. Flux feels like Kubernetes-native building blocks; Argo CD like a delivery product with a rich UI.

   From lesson 06 · Flux and Argo CD

8. Q8. Which object tells Flux where to fetch desired state from?

   1. AApplication
   2. BA source object such as GitRepository, OCIRepository or HelmRepository
   3. CConfigMap
   4. DDeployment
   Show answer

   B. Sources fetch artifacts; Kustomization and HelmRelease objects apply them.

   From lesson 06 · Flux and Argo CD

9. Q9. A team wants a visual view of every app's sync and health, SSO and per-team access for developers. Which fits more naturally?

   1. AFlux
   2. BArgo CD
   3. CNeither
   4. Dkubectl
   Show answer

   B. Argo CD's UI, SSO and project-based RBAC are its main strengths. Flux can get a UI through third-party tools.

   From lesson 06 · Flux and Argo CD

10. Q10. What makes a delivery 'progressive'?

    1. ADeploying slowly by hand
    2. BExposing a new version to a growing share of traffic in steps, checking metrics at each step, and rolling back automatically if they degrade
    3. CUsing several Git branches
    4. DDeploying at night
    Show answer

    B. Small exposure first, evidence at each step, automatic decisions: a bad release hurts few users briefly.

    From lesson 07 · Progressive delivery

11. Q11. How does GitOps fit with progressive delivery?

    1. AThey conflict
    2. BGit declares the new version (the Rollout/Canary spec with its steps); the rollout controller executes the steps and analysis in the cluster
    3. CRollouts replace Git
    4. DThe controller edits Git
    Show answer

    B. The desired end state and the rollout strategy are in Git; the controller handles the time-based journey there.

    From lesson 07 · Progressive delivery

12. Q12. What should the analysis measure?

    1. ACPU only
    2. BUser-facing signals of the new version: error rate and latency (ideally compared against the stable version), plus key business metrics
    3. CBuild time
    4. DNumber of pods
    Show answer

    B. Promote on the same symptoms you page on (SLO signals), not on resource usage.

    From lesson 07 · Progressive delivery