KCNA GitOps and Continuous Delivery 2 — Questions and Answers
Question 1: Flux CD synchronizes Kubernetes clusters using which model?
- Push-based, triggered by external CI webhook calls
- Pull-based, with controllers running inside the cluster watching Git (Correct answer)
- Manual, requiring operator approval for each synchronization
- Event-driven, triggered exclusively by container registry update notifications
Correct answer: Pull-based, with controllers running inside the cluster watching Git
Flux CD uses a pull-based model where controllers (source-controller, kustomize-controller, etc.) run inside the cluster and continuously watch Git repositories for changes to apply.
Question 2: What is the 'app of apps' pattern in ArgoCD?
- A pattern where one ArgoCD Application manages other ArgoCD Application resources (Correct answer)
- A pattern for co-locating multiple containers within a single Kubernetes pod
- A pattern for sharing configuration between cooperating microservices
- A pattern for routing traffic between multiple application versions
Correct answer: A pattern where one ArgoCD Application manages other ArgoCD Application resources
The 'app of apps' pattern uses a root ArgoCD Application pointing to a Git directory that contains manifests for additional ArgoCD Applications, enabling hierarchical management of many applications.
Question 3: What role does Kustomize play in a GitOps workflow?
- It is a secret encryption tool for storing credentials in Git
- It allows customization of Kubernetes YAML manifests through overlays without modifying original base files (Correct answer)
- It is a package manager equivalent to Helm for templating manifests
- It builds container images as part of the GitOps pipeline
Correct answer: It allows customization of Kubernetes YAML manifests through overlays without modifying original base files
Kustomize lets users apply environment-specific patches and overlays on top of base Kubernetes manifests without editing the originals, enabling DRY, environment-aware GitOps configurations.
Question 4: In a GitOps workflow, what event typically triggers a deployment to production?
- A manual kubectl apply run by an operator
- A merge into the target branch (e.g., main) in the Git repository (Correct answer)
- A scheduled cron job running in the CI system every night
- A direct API call sent to the Kubernetes API server
Correct answer: A merge into the target branch (e.g., main) in the Git repository
In GitOps, merging a pull request into the target branch signals 'this change is approved,' causing the GitOps operator to detect the new desired state and synchronize the cluster.
Question 5: How does ArgoCD represent the synchronization status of a managed application?
- It sends email alerts whenever an application is out of sync
- It displays a Synced or OutOfSync status and supports both auto-sync and manual sync modes (Correct answer)
- It automatically rolls back the application to the last known good state on any sync failure
- It blocks new Git commits to the repository when the cluster is out of sync
Correct answer: It displays a Synced or OutOfSync status and supports both auto-sync and manual sync modes
ArgoCD displays each application's health and sync status (Synced/OutOfSync) and can be configured for automatic synchronization or to require manual approval before applying changes.
Question 6: What does a GitOps operator's self-healing capability accomplish?
- It repairs corrupted or force-pushed Git repositories
- It automatically restores the cluster to the Git-defined desired state whenever drift is detected (Correct answer)
- It corrects syntax errors found in Kubernetes YAML manifests
- It restarts failed CI/CD pipeline jobs when they time out
Correct answer: It automatically restores the cluster to the Git-defined desired state whenever drift is detected
Self-healing means the GitOps operator detects any drift (e.g., a manually deleted resource) and automatically re-applies the desired state from Git without human intervention.
Question 7: Which Git branching strategy is commonly paired with GitOps for environment promotion?
- A single shared branch used for all environments simultaneously
- Environment-specific branches or directories within the repository to separate dev, staging, and production (Correct answer)
- Feature branches that deploy changes directly to production on push
- A merge-free workflow using cherry-picking across all environments
Correct answer: Environment-specific branches or directories within the repository to separate dev, staging, and production
GitOps environments are commonly separated by branches (e.g., dev, staging, main) or by directories within a single branch, enabling controlled promotion of changes through each environment.
KCNA GitOps and Continuous Delivery 2
Flux CD synchronizes Kubernetes clusters using which model?