CGOA Gitops Terminology Practice Questions

Explanation: Flux provides a mechanism to ignore specific resources during reconciliation using annotations on Kustomization resources. By adding the `kustomize.toolkit.fluxcd.io/reconcile: disabled` annotation, you can instruct Flux to skip reconciliation for those resources, which is essential for resources that are managed externally or should not be altered.

Explanation: Option A is correct because in a pull-based deployment model the in-cluster agent (e.g., Argo CD or Flux) continuously reconciles the desired state from the Git repository, so no external CI/CD system needs network access or credentials to reach the cluster API. Option D is correct because the pull-model operator/agent runs inside the cluster and therefore must itself hold the RBAC permissions and cluster access required to apply manifests and reconcile resources. Option B is wrong because pull models scale to clusters of any size; the agent's reconciliation loop is not limited to small clusters. Option C is wrong because GitOps is characteristically implemented with pull-based reconciliation, not push. Option E is wrong because push models require external systems to hold cluster credentials, which generally increases rather than reduces the attack surface.

Explanation: In an Argo CD Application, the destination namespace field specifies which Kubernetes namespace the application's resources will be deployed into. It restricts the deployment target, ensuring manifests are applied to the intended namespace rather than the default. This is a deployment scoping mechanism, not a runtime isolation feature.

Explanation: Option A is correct because in GitOps the desired state of each environment is declared in Git, so promoting a change to production is done by updating the manifest file in the 'production' directory and letting the GitOps controller (e.g., Argo CD or Flux) reconcile the cluster to that new declared state. Option E is correct because updating a Git tag to point to a new release is a standard GitOps promotion mechanism: the tag references the immutable artifact/commit, and the controller detects the change and rolls it out. Option B is not a GitOps workflow because running a manual script on the live server mutates the environment outside of Git, breaking the single source of truth and drift detection. Option C is not a promotion workflow because reinstalling the Kubernetes cluster is a destructive infrastructure action, not a controlled change promotion. Option D is not GitOps because using a UI wizard to bypass Git circumvents the declarative, version-controlled pipeline that defines GitOps.

Explanation: Option A is correct because maintaining separate repositories per environment (e.g., a dev repo and a prod repo) is a recognized pattern for isolating environment-specific configuration, allowing each environment's settings, branches, and access controls to evolve independently. Option D is correct because organizing configurations into distinct folders such as dev/ and prod/ is a standard directory-based structuring approach that keeps environment-specific files (e.g., application-dev.yml vs application-prod.yml) cleanly separated within one codebase. Option B is not a standard structural pattern for environment configuration because an external database is a storage mechanism, not a way to organize or lay out configuration files. Option C is incorrect because hardcoding environment names into deployment scripts creates brittle, non-reusable automation rather than a structured configuration scheme. Option E is incorrect because embedding all environments in a single flat file mixes concerns, invites key collisions, and makes environment-specific overrides error-prone.