Skip to content

Quiz: GitOps

← Back to quiz index

24 questions

L1 (12 questions)

1. What is GitOps and how does it differ from traditional CI/CD?

Show answer GitOps uses a Git repo as the single source of truth for desired infrastructure state. A controller (Argo CD, Flux) continuously reconciles live state to match Git. Traditional CI/CD pushes changes; GitOps pulls desired state. Git history becomes the audit log.

2. What is drift detection in GitOps?

Show answer The GitOps controller compares live cluster state against the desired state in Git. Any difference is drift — caused by manual kubectl edits, other controllers, or admission webhooks mutating resources. The controller reports or auto-corrects drift.

3. What is the difference between desired state and live state in GitOps?

Show answer Desired state is what's declared in Git (manifests, Helm values). Live state is what's actually running in the cluster. The GitOps controller's job is to continuously converge live state toward desired state.

4. Why is manual kubectl apply discouraged in a GitOps workflow?

Show answer It creates drift — live state diverges from Git. The GitOps controller will either revert the change (if auto-sync) or show OutOfSync. All changes should go through Git so they are reviewed, versioned, and auditable.

5. What is the core principle of GitOps?

Show answer Git is the single source of truth for desired state. An operator (ArgoCD, Flux) continuously reconciles the live cluster to match the declared state in Git. Changes happen via pull requests, not manual kubectl commands.

6. What is the difference between push-based and pull-based GitOps?

Show answer Push: CI pipeline applies changes to the cluster (e.g., kubectl apply in Jenkins). Pull: an in-cluster operator polls Git and applies changes itself (ArgoCD, Flux). Pull is more secure — no external system needs cluster credentials.

7. What is 'drift' in GitOps and how is it handled?

Show answer Drift = live state differs from desired state in Git. Causes: manual kubectl edits, external controllers, failed syncs. The GitOps operator detects drift and either auto-corrects or alerts. ArgoCD shows OutOfSync status; Flux logs drift events.

8. How do you safely roll back a deployment in GitOps?

Show answer Revert the commit in Git (git revert) and let the operator reconcile. Do NOT manually kubectl rollout undo — that creates drift. In an emergency, you can sync to a specific Git revision in ArgoCD, but follow up with a proper Git revert.

9. What is the difference between ArgoCD Application and ApplicationSet?

Show answer Application = one ArgoCD app managing one set of manifests for one target. ApplicationSet = a template that generates multiple Applications dynamically (e.g., one per cluster, per environment, or per team). Reduces boilerplate for multi-cluster deployments.

10. Why is it important to separate app config repos from app code repos in GitOps?

Show answer 1. Deployment frequency differs from code change frequency.
2. Avoids triggering unnecessary CI builds when only config changes.
3. Different access controls — SRE team manages config, dev team manages code.
4. Clear audit trail for infrastructure changes.

11. What is reconciliation in GitOps?

Show answer The continuous loop where the operator compares desired state (Git) with actual state (cluster) and takes action to converge them. Reconciliation runs on a schedule (e.g., every 3 minutes) and on Git webhook events. It is the core feedback loop that makes GitOps self-healing.

12. What are sync waves and hooks in ArgoCD?

Show answer Sync waves control the order of resource creation (lower wave number = applied first). Hooks run at specific phases: PreSync, Sync, PostSync, SyncFail. Use waves for dependencies (namespace before deployment). Use hooks for migrations, tests, or notifications.

L2 (12 questions)

1. What happens when a GitOps sync fails?

Show answer The controller marks the application as OutOfSync or Degraded. It does not keep retrying destructive operations. Check:
1. Rendered manifests for errors.
2. Resource validation failures.
3. Webhook rejections.
4. Insufficient RBAC. Fix in Git and push — the controller will retry.

2. How do you safely roll back in a GitOps workflow?

Show answer Revert the commit in Git (git revert, not force-push). The GitOps controller detects the new desired state and syncs. Alternatively, use the controller's rollback feature (Argo CD UI) for emergencies, but follow up with a Git revert to keep Git as source of truth.

3. How do you handle secrets in a GitOps repository?

Show answer Never store plaintext secrets in Git. Options:
1. Sealed Secrets (encrypt with public key, controller decrypts).
2. External Secrets Operator (syncs from Vault/AWS SM).
3. SOPS-encrypted files in Git. The GitOps controller applies the decrypted secret.

4. What is a safe rollout pattern in GitOps for a risky change?

Show answer 1. Progressive delivery: Canary or blue-green via Argo Rollouts or Flagger.
2. Sync only to staging first; promote to prod after validation.
3. Use sync waves or hooks for ordering.
4. Manual sync approval gates for production.

5. How do GitOps sync waves work?

Show answer Sync waves (Argo CD) order resource application. Resources with lower wave numbers are applied first and must be healthy before higher waves proceed. Use for: namespaces before deployments, CRDs before CRs, config before apps.

6. An ArgoCD application shows OutOfSync but auto-sync is enabled. What do you check?

Show answer 1. Sync errors in the app status (failed hooks, resource conflicts).
2. Retry policy — auto-sync retries may be exhausted.
3. Resource exclusions in ArgoCD config.
4. Mutating webhooks or controllers modifying resources after sync (causes perpetual drift).
5. Diff shows fields ArgoCD can't control — add ignoreDifferences.

7. How do you handle secrets in a GitOps workflow?

Show answer Options:
1. Sealed Secrets — encrypt in Git, controller decrypts in cluster.
2. External Secrets Operator — references secrets from Vault/AWS SM.
3. SOPS — encrypt YAML values, decrypt during sync. Never store plaintext secrets in Git, even in private repos.

8. What happens if you delete a resource from Git in a GitOps workflow?

Show answer Depends on prune policy. With pruning enabled, the operator deletes the resource from the cluster. Without pruning, the resource becomes an orphan (exists in cluster but not in Git). ArgoCD shows it as 'OutOfSync — missing in Git'. Best practice: enable pruning with caution.

9. How do you implement progressive delivery with GitOps?

Show answer Use Argo Rollouts or Flagger alongside ArgoCD/Flux. Define canary or blue-green strategy in Rollout resources. The rollout controller manages traffic shifting and promotion. Integrate with metrics (Prometheus) for automated analysis and rollback on error rate thresholds.

10. How do you manage multiple environments (dev/staging/prod) in GitOps?

Show answer Options:
1. Directory per environment (envs/dev/, envs/prod/) with Kustomize overlays.
2. Branch per environment (not recommended — merge conflicts).
3. Helm values files per environment.
4. ApplicationSet generators with cluster/env labels. Best practice: directory or overlay approach.

11. What are common causes of GitOps sync failures?

Show answer 1. Invalid YAML/manifests (syntax errors).
2. Namespace doesn't exist.
3. CRD not installed (resource type unknown).
4. RBAC — operator service account lacks permissions.
5. Resource conflicts (another controller owns the resource).
6. Immutable field changes (e.g., Job spec).
7. Webhook rejections.

12. How do you debug why an ArgoCD sync is slow?

Show answer 1. Check if many resources are being synced (break into smaller apps).
2. Look for sync waves/hooks that block progression.
3. Check ArgoCD controller resource usage (CPU/memory).
4. Verify Git repo is accessible and not rate-limited.
5. Check for large manifests or Helm charts with many templates.