Certified GitOps Associate (CGOA, CNCF/Linux Foundation) (CGOA) (CGOA) — Questions 301–323

Option B is correct because GitOps requires the desired state to be expressed declaratively in manifest files (YAML) rather than through imperative commands like 'kubectl apply' or 'kubectl edit', so the cluster state can be versioned and reproduced. Option C is correct because Git must serve as the single source of truth, meaning all environment and application configuration lives in Git repositories and any change is made via commits and pull requests, not directly on the cluster. Option D is correct because a GitOps agent (e.g., Argo CD or Flux) must continuously reconcile the live cluster state with the desired state stored in Git, typically using a pull-based model that detects drift and automatically corrects it.

Option A is not correct because a manual deployment document in a wiki is not version-controlled, not machine-readable, and cannot drive automated reconciliation, which contradicts GitOps principles. Option E is not correct because adding manual approvals increases friction and human intervention, whereas GitOps emphasizes automated, auditable, and repeatable delivery driven by Git commits and CI checks.

Option A is correct because requiring GPG signing for commits ensures that only authorized developers can push changes to the Git repository, which is the single source of truth in GitOps; unsigned or tampered commits could otherwise inject malicious manifests into the cluster. Option C is correct because implementing RBAC for the Git repository restricts who can read, write, or merge to the branches that the GitOps operator reconciles, preventing unauthorized changes that would be automatically deployed. Option D is correct because storing secrets in external stores like HashiCorp Vault keeps sensitive credentials out of Git, where they would be exposed in plaintext and replicated to every cluster that syncs the repository.

Option B is not correct because hardcoded passwords in Kubernetes manifests are a security anti-pattern that leaks credentials into version control. Option E is not correct because granting the GitOps operator cluster-admin access by default violates least privilege and dramatically expands the blast radius of a compromised operator.

Option A is correct because a core GitOps challenge is configuration drift — the live cluster state diverging from the desired state declared in Git — which occurs when changes are made directly to the cluster (e.g., via kubectl) or when reconciliation fails, requiring continuous sync tools like Argo CD or Flux to detect and remediate it. Option D is correct because Git repositories are plaintext and version-controlled, so storing Kubernetes Secrets, credentials, and tokens directly in Git exposes sensitive data; teams must adopt solutions such as Sealed Secrets, SOPS, External Secrets Operator, or HashiCorp Vault to manage secrets securely. Option B is not a GitOps challenge because Git is the foundational prerequisite of GitOps — the entire model depends on a Git repository as the single source of truth, so its absence is a setup failure rather than a common operational challenge.

Option C is not a GitOps-specific challenge because having many developers is a general team-scaling concern, and Git's branching, pull-request, and review workflows are specifically designed to handle large contributor bases. Option E is not a challenge because documentation volume is unrelated to GitOps mechanics; if anything, GitOps improves traceability through commit history and declarative manifests.

In GitOps, the desired state of each environment is stored declaratively in Git, and a controller (e.g., Argo CD or Flux) continuously reconciles the live state to match it. Using dedicated directories per environment within a single repository (e.g., /envs/dev, /envs/staging, /envs/prod) allows each environment to have its own manifests and configuration while sharing common base resources via Kustomize or Helm. This structure supports promotion workflows (e.g., merging changes from dev to staging to prod) and provides clear separation without the overhead of multiple repositories.

It also aligns with the principle of a single source of truth for all environments, making it easier to audit and manage drift.

Option B is correct because a GitOps controller runs a continuous reconciliation loop that constantly compares the desired state in Git with the live cluster state and corrects drift, whereas a CI pipeline executes only once per trigger and then stops, so it cannot provide ongoing convergence or feedback. Option C is correct because keeping the CI pipeline from holding direct write credentials to the Kubernetes API enforces least privilege: if the pipeline is compromised, the attacker cannot directly mutate cluster resources, and all changes must instead flow through Git where they are reviewed, versioned, and auditable, greatly reducing the blast radius. Option A is wrong because binary compilation is a CI/build responsibility, not something the GitOps controller does; the controller only applies declarative manifests.

Option D is wrong because bypassing the Git repository for production hotfixes directly contradicts GitOps principles, which require Git as the single source of truth. Option E is wrong because a CI pipeline is technically capable of deploying to a cluster (e.g., via kubectl or Helm with credentials); the separation is a deliberate security and architectural choice, not a physical limitation.

Option A is correct because a pull-based GitOps workflow requires a Git repository that stores the declarative manifests (YAML/Helm/Kustomize) representing the desired state of the system, which serves as the single source of truth. Option B is correct because a Kubernetes cluster is the target runtime environment where the applications defined in those manifests are actually deployed and reconciled. Option C is correct because a GitOps controller such as Argo CD or Flux runs inside the cluster, continuously pulls the desired state from Git, and reconciles it against the live cluster state.

Option D is not essential and is in fact contrary to the pull model, since a CI server with cluster-admin access implies a push-based deployment and violates least-privilege principles. Option E is not required because the cluster state is stored in etcd and the desired state in Git; no dedicated external database is needed for GitOps.

Option B is correct because SealedSecrets encrypts secrets with a controller-held private key so the ciphertext can be safely committed to a Git repository and decrypted only inside the cluster, which fits GitOps' declarative, version-controlled workflow. Option C is correct because an external secret manager such as HashiCorp Vault keeps the actual secret material outside Git and injects it at runtime, so the repository stores only references or paths rather than sensitive values. Option D is correct because regularly rotating secrets according to security policies limits the blast radius of any leaked credential and is a core secrets-management control.

Option A is wrong because sharing secrets in cleartext via team chat exposes them to logs, backups, and unauthorized members. Option E is wrong because base64 is merely an encoding, not encryption, so anyone with repository access can trivially decode the secrets.

Option C is correct because GitOps requires an automated agent (such as Argo CD or Flux) that continuously pulls the desired state from Git and reconciles it into the cluster, rather than relying on external push-based deployments. Option D is correct because the CNCF GitOps Working Group defines the desired state as versioned and immutable, with Git serving as the single source of truth whose history is preserved. Option E is correct because the entire system must be described declaratively (for example, Kubernetes YAML manifests) so the agent can compare desired versus actual state and converge them.

Option A is incorrect because GitOps favors automated reconciliation, not mandatory manual approval for every production deployment. Option B is incorrect because GitOps is fundamentally pull-based, not push-based, so push-based CI/CD pipelines contradict the model.

Option C is correct because cryptographically signed commits (e.g., using GPG or SSH signatures verified via git commit -S and git verify-commit) provide non-repudiable proof of who authored a change, which is essential for auditability in a GitOps repository. Option D is correct because detailed commit logs capturing author identity and timestamp (as recorded in the commit object's author/committer fields and shown by git log) create a traceable history of every change, satisfying audit requirements. Option A is incorrect because restricting pushes to a single admin user does not by itself provide an audit trail and actually reduces traceability of who made changes.

Option B is incorrect because using private email addresses obscures author identity rather than making the repository more auditable. Option E is incorrect because storing files as binary blobs prevents meaningful diffs and review of changes, undermining auditability.