Certified GitOps Associate (CGOA, CNCF/Linux Foundation) (CGOA) CGOA Questions 76–150 | Page 2/5

MCQeasy

What does the 'prune' policy in GitOps do?

A.It deletes resources from the cluster that are no longer in Git.

B.It cleans up old container logs.

C.It synchronizes the Git repo with the latest upstream changes.

D.It restarts pods that have been running for too long.

AnswerA

Pruning compares live cluster resources against the Git-declared desired state and removes anything absent from Git, preventing configuration drift. This enforces Git as the single source of truth, satisfying the GitOps reconciliation requirement that cluster state matches the repository.

Why this answer

The prune policy in GitOps deletes resources from the cluster that are no longer present in Git, ensuring the cluster state matches the declared desired state exactly. Without pruning, removed manifests would leave orphaned resources running, causing drift between Git and the live cluster.

Exam trap

CGOA often tests the confusion between pruning and syncing — candidates may pick the sync option, but pruning specifically means deleting cluster resources that no longer exist in Git.

How to eliminate wrong answers

Option B is wrong because cleaning up old container logs is a logging or retention concern, not a GitOps reconciliation behavior. Option C is wrong because synchronizing the Git repo with upstream changes describes a Git pull or sync operation, not pruning, which acts on cluster resources. Option D is wrong because restarting long-running pods is a remediation or liveness-probe action, not a prune policy, which is about removing resources absent from Git.

Full explanation →

Multi-Selectmedium

Which THREE components are essential for a complete GitOps CI/CD pipeline?

Select 3 answers

A.An automated controller that reconciles the cluster to the Git state.

B.A CI system that updates the manifest repository.

C.A human-operated dashboard for manual deployment.

D.A version control system (Git) acting as the source of truth.

E.A dedicated server for storing logs.

AnswersA, B, D

The reconciling controller is the mechanism that continuously compares live cluster state against the Git-declared desired state and applies corrections, closing the loop automatically. Without it, Git remains only a record of intent and nothing enforces convergence, so drift persists.

Why this answer

Option A is correct because GitOps fundamentally relies on an automated controller (e.g., Argo CD or Flux) running in the cluster that continuously reconciles the live state to match the desired state declared in Git. Option B is correct because a CI system (e.g., Jenkins, GitHub Actions, GitLab CI) is needed to build artifacts and commit updated manifests to the manifest repository, closing the loop between code changes and deployment. Option D is correct because Git serves as the single source of truth, storing the declarative desired state that the controller reconciles against, which is the defining characteristic of GitOps.

Option C is not essential because GitOps emphasizes automated, declarative deployments rather than manual dashboard-driven operations, and Option E is not essential because log storage is an observability concern, not a core component of the GitOps CI/CD pipeline itself.

Exam trap

CGOA often tests whether candidates include non-essential operational components (dashboards, log servers) as 'essential' GitOps pipeline parts — the trap is confusing observability or manual tooling with the core Git + CI + controller triad.

Full explanation →

Multi-Selecteasy

Which TWO of the following tools allow for GitOps policy enforcement?

Select 2 answers

A.OPA Gatekeeper

B.Helm

C.ArgoCD

D.Flux

E.Kyverno

AnswersA, E

OPA Gatekeeper enforces policies at the Kubernetes admission-control layer, rejecting non-compliant manifests before they reach the cluster. This satisfies GitOps enforcement because the declarative Git source remains the single truth, yet Gatekeeper blocks any drift or policy-violating resource at apply time, independent of the CI pipeline that merged it.

Why this answer

OPA Gatekeeper (A) is correct because it is a Kubernetes admission controller that enforces policies written in Rego, allowing GitOps pipelines to validate and reject non-compliant manifests before they are applied to the cluster. Kyverno (E) is also correct because it provides Kubernetes-native policy enforcement via validating, mutating, and generating admission rules, which integrates with GitOps workflows to ensure only policy-compliant resources are deployed. Helm (B) is a package manager for templating and deploying Kubernetes manifests, not a policy enforcement engine.

ArgoCD (C) and Flux (D) are GitOps continuous delivery tools that sync cluster state with Git, but they do not themselves enforce policy; they rely on tools like Gatekeeper or Kyverno for that purpose.

Exam trap

CGOA often tests the confusion between GitOps delivery tools (ArgoCD, Flux) and policy engines (Gatekeeper, Kyverno), causing candidates to select delivery tools as policy enforcement solutions.

Full explanation →

Multi-Selecthard

You are using Flux to manage a multi-tenant cluster. You want to enforce that all Kustomizations in a specific namespace can only deploy resources that are allowed by a policy. You have decided to use OPA Gatekeeper. Which two resources are required to define and enforce a policy in Gatekeeper? (Choose two.)

Select 2 answers

A.Constraint

B.Kustomization

C.Policy

D.ConstraintTemplate

E.ConfigMap

AnswersA, D

A Constraint is an instance of a ConstraintTemplate that specifies the scope (e.g., which namespaces or resources) and the parameters. It is the resource that actually enforces the policy. You need both a ConstraintTemplate and a Constraint to define and apply a policy.

Why this answer

In OPA Gatekeeper, a ConstraintTemplate defines the policy logic and schema, while a Constraint is an instance that specifies the scope and parameters. Together, they define and enforce a policy. The other options are either not Gatekeeper resources or serve different purposes.

Exam trap

The trap here is thinking that a Policy resource exists in Gatekeeper, or that a Kustomization can enforce policy logic.

Full explanation →

Multi-Selecteasy

Which TWO of the following are core principles of the GitOps model?

Select 2 answers

A.All code is written in Go.

B.Changes are automatically reconciled to match the declared state.

C.Manual updates are preferred for emergency fixes.

D.The desired state is defined in a version-controlled repository.

E.Developers have direct SSH access to the production cluster.

AnswersB, D

A reconciliation controller continuously compares live cluster state against the declared state and converges them automatically, correcting drift without manual intervention. This closed-loop convergence, rather than pipeline-triggered deployment alone, is what satisfies the GitOps principle of automated reconciliation.

Why this answer

Option B is correct because GitOps relies on a continuous reconciliation loop (typically implemented by an operator such as Argo CD or Flux) that detects drift between the live cluster and the declared state and automatically converges the running system back to that declared state. Option D is correct because GitOps treats a version-controlled repository (usually Git) as the single source of truth, where the desired state of infrastructure and applications is declaratively stored, giving full audit history, reviewability, and rollback via commits and reverts. The remaining options do not belong: A is false because GitOps is language-agnostic and does not require Go, C contradicts GitOps since emergency fixes should still flow through the declarative, version-controlled pipeline rather than manual changes, and E is false because GitOps deliberately avoids direct human access to production, relying on automated reconciliation instead of SSH.

Exam trap

CGOA often tests the misconception that GitOps allows manual emergency fixes or requires a specific language — the core principles are declarative state, version control, automatic pull, and continuous reconciliation.

Full explanation →

MCQeasy

Which GitOps tool is primarily associated with the 'pull' deployment model?

A.Jenkins

B.Flux

C.Ansible

D.Terraform

AnswerB

Flux continuously reconciles cluster state by pulling manifests from Git repositories, satisfying the pull-model constraint where the cluster initiates changes rather than receiving external pushes. Its controllers watch sources and apply drift correction autonomously, which matches the question's requirement precisely.

Why this answer

Flux is a CNCF-graduated GitOps operator that implements the pull model: an in-cluster agent watches Git repositories and pulls changes into the cluster, rather than an external system pushing deployments in. This pull architecture is the defining characteristic of modern GitOps tooling and is why Flux (alongside Argo CD) is the canonical example.

Exam trap

CGOA often tests the push-vs-pull distinction, and candidates mistakenly associate any automation tool (Jenkins, Ansible, Terraform) with GitOps — the exam expects you to recognize that only in-cluster pull-based reconcilers like Flux and Argo CD qualify.

How to eliminate wrong answers

Option A is wrong because Jenkins is a CI server that typically uses a push model — it builds artifacts and pushes deployments to the cluster using credentials, which is the opposite of the pull-based GitOps pattern. Option C is wrong because Ansible is a configuration management tool that pushes changes over SSH or APIs from a control node; it has no in-cluster reconciliation agent. Option D is wrong because Terraform is an infrastructure provisioning tool that applies state via a push-style plan/apply workflow, not a continuous pull-based reconciler.

Full explanation →

Multi-Selecteasy

A team is reviewing their deployment practices against OpenGitOps standards. Which THREE conditions are required to satisfy the 'Declarative Desired State' and 'Versioned and Immutable State' principles?

Select 3 answers

A.The target system's desired state is expressed in a software-interpretable, declarative format like YAML or JSON.

B.The desired state is stored in a version-controlled repository that maintains an append-only change history.

C.Every state revision is uniquely identified (e.g., by a Git commit SHA) and fully reproducible.

D.Live cluster state is permitted to override repository configurations during peak traffic periods.

E.System changes are made by executing manual shell scripts directly on production control plane nodes.

AnswersA, B, C

Declarative desired state requires the target system's configuration to be expressed in a software-interpretable format such as YAML or JSON, so tooling can read and reconcile it automatically. This satisfies the principle's demand for machine-readable state rather than imperative scripts or manual configuration.

Why this answer

Option A is correct because the OpenGitOps 'Declarative Desired State' principle requires that the intended state of the system be expressed in a declarative, software-interpretable format such as YAML or JSON, so tooling can read and reconcile it automatically. Option B is correct because 'Versioned and Immutable State' requires the desired state to live in a version-controlled repository whose history is append-only, meaning changes are added as new revisions rather than overwriting or deleting prior ones. Option C is correct because each revision must be uniquely identifiable—typically by a Git commit SHA—and fully reproducible, so any past state can be reconstructed and audited.

Option D does not belong because allowing live cluster state to override the repository breaks the single source of truth and the immutability of the declared desired state. Option E does not belong because manual shell scripts executed directly on production control plane nodes are imperative, unversioned, and non-reproducible, contradicting both principles.

Exam trap

CGOA often tests the specific conditions of OpenGitOps principles, and candidates may confuse optional best practices with required conditions, or select options that violate the single source of truth.

Full explanation →

MCQhard

Your team is using a pull-based GitOps pattern. Which component is responsible for initiating the communication to the Git repository to check for updates?

A.The developer's local kubectl client.

B.The agent running inside the Kubernetes cluster.

C.The CI/CD pipeline pushes updates to the cluster.

D.The Git server pushes changes to the cluster webhook.

AnswerB

In pull-based GitOps, the in-cluster agent (such as Flux or Argo CD) polls the Git repository and pulls desired state, so it initiates outbound communication; the repository never pushes to the cluster, satisfying the pull constraint.

Why this answer

In a pull-based GitOps model, an agent (such as Argo CD or Flux) runs inside the Kubernetes cluster and periodically polls the Git repository to detect desired-state changes. The agent initiates the outbound connection to Git, then reconciles the cluster state to match what is declared in the repository. This pull model keeps cluster credentials out of the CI system and gives the cluster control over when updates are applied.

Exam trap

The trap here is confusing pull-based GitOps with push-based CI/CD — candidates see 'webhook' or 'pipeline' and assume the Git server or CI system initiates communication, when in pull-based GitOps the in-cluster agent always initiates the connection to Git.

How to eliminate wrong answers

Option A is wrong because the developer's local kubectl client is used for manual interaction with the cluster, not for GitOps reconciliation — it plays no role in polling Git for desired state. Option C is wrong because it describes a push-based model where CI/CD pushes to the cluster, which is the opposite of pull-based GitOps. Option D is wrong because in pull-based GitOps the Git server does not push changes to the cluster; the in-cluster agent pulls from Git, and webhooks only serve as an optimization to trigger an immediate pull rather than the primary mechanism.

Full explanation →

Multi-Selectmedium

Which TWO are common pitfalls in a GitOps implementation?

Select 2 answers

A.Using Git for version control.

B.Having too many branches.

C.Allowing manual 'kubectl edit' changes.

D.Automating too many processes.

E.Committing plaintext secrets to Git.

AnswersC, E

Manual kubectl edit changes bypass Git entirely, so the cluster diverges from the declared desired state and the next reconciliation overwrites the edit. This breaks Git's role as the single source of truth, making it a common GitOps pitfall.

Why this answer

Option C is correct because allowing manual 'kubectl edit' changes breaks the GitOps principle that Git is the single source of truth; the live cluster state drifts from the declared state, and the next reconciliation by tools like Argo CD or Flux will either overwrite the manual change or leave the cluster inconsistent. Option E is correct because committing plaintext secrets to Git exposes credentials to anyone with repository read access and permanently stores them in Git history, which is a well-known GitOps pitfall; secrets should instead be managed with Sealed Secrets, External Secrets Operator, SOPS, or a vault. Option A is not a pitfall—using Git for version control is the foundational requirement of GitOps.

Option B is not inherently a pitfall; branching strategy is a workflow choice, and many successful GitOps setups use trunk-based development or a modest number of branches. Option D is not a pitfall—automation is the goal of GitOps, and automating more processes generally increases consistency rather than causing problems.

Exam trap

The trap is that candidates may think any Git-related practice (like many branches) is a GitOps pitfall, or that automation itself is risky, when the actual pitfalls are violations of the Git-as-source-of-truth principle and security hygiene.

Full explanation →

MCQeasy

Which of these is a primary benefit of 'Infrastructure as Code' (IaC) in a GitOps workflow?

A.It replaces the need for monitoring.

B.It enables the entire infrastructure to be versioned and reconciled automatically.

C.It reduces the number of developers needed.

D.It makes the cloud provider cheaper.

AnswerB

Versioning infrastructure as code lets every change be committed, reviewed and rolled back through Git history, while automated reconciliation continuously aligns real infrastructure with that versioned definition. This satisfies the GitOps requirement that infrastructure state remains auditable and self-correcting.

Why this answer

In a GitOps workflow, IaC's primary benefit is that the entire infrastructure is expressed declaratively, stored in Git, and continuously reconciled by a controller. This gives versioning, auditability, rollback via git revert, and automatic drift correction — the defining characteristics of GitOps. The infrastructure becomes a versioned artifact just like application code.

Exam trap

CGOA often tests whether candidates recognise IaC's core value as versioning and reconciliation, not cost savings or headcount reduction — the distractors appeal to business assumptions rather than technical reality.

How to eliminate wrong answers

Option A is wrong because IaC does not replace monitoring — monitoring and observability remain essential for detecting runtime issues, performance problems, and security events that IaC cannot predict. Option C is wrong because IaC does not reduce the number of developers needed; it changes how they work (declarative vs. manual) but does not eliminate the need for engineering expertise. Option D is wrong because IaC does not inherently make the cloud provider cheaper — it can improve cost efficiency through consistency and repeatability, but cost reduction is a possible outcome, not a primary benefit, and depends on usage patterns.

Full explanation →

Multi-Selectmedium

Which TWO of the following help ensure successful multi-cluster GitOps rollouts? (Select two)

Select 2 answers

A.Deploying to all clusters at the same time.

B.Using only one Git repository for all cluster configurations.

C.Using canary deployment phases per cluster group.

D.Grouping clusters by geography or environment for staggered rollouts.

E.Hardcoding cluster IPs in the manifest files.

AnswersC, D

Canary phases promote a release through successive cluster groups, exposing each increment to real traffic before widening it. This limits blast radius per stage and provides verification checkpoints, satisfying the stem's requirement for successful multi-cluster GitOps rollouts rather than a single simultaneous push.

Why this answer

Option C is correct because canary deployment phases per cluster group let you roll out changes to a small subset of clusters first, validate health and metrics, and only then promote the change to the remaining groups, which limits blast radius and enables safe progressive delivery. Option D is correct because grouping clusters by geography or environment (for example, dev → staging → prod, or region-by-region) supports staggered rollouts so that failures are detected in lower-risk groups before reaching production or other regions. Option A is wrong because deploying to all clusters simultaneously maximizes blast radius and removes any opportunity to catch a bad change before it affects everything.

Option B is wrong because a single Git repository for all cluster configurations is not a requirement for successful multi-cluster GitOps and can create coupling and coordination problems; separate repos or directory structures are common and valid. Option E is wrong because hardcoding cluster IPs in manifests makes configurations brittle and non-portable, breaking the declarative, environment-agnostic nature of GitOps.

Exam trap

CGOA often tests the trade-offs between speed and safety in multi-cluster rollouts, and candidates may incorrectly think that deploying to all clusters at once or using a single repo is efficient, ignoring risk and isolation.

Full explanation →

Multi-Selecthard

Which THREE of the following represent advanced GitOps patterns for multi-cluster management? (Select three)

Select 3 answers

A.ApplicationSets with custom generators.

B.GitOps-driven traffic management with Service Mesh.

C.Policy-as-Code for multi-cluster compliance.

D.Always using a single cluster for everything.

E.Using manual shell scripts for cluster provisioning.

AnswersA, B, C

ApplicationSets with custom generators let one definition target many clusters, satisfying the multi-cluster constraint. Generators such as cluster, git, or matrix dynamically produce per-cluster Applications, so a single source of truth fans out configuration without duplicating manifests.

Why this answer

Option A is correct because Argo CD ApplicationSets use generators (such as cluster, git, list, matrix, and merge generators) to automatically template and deploy Applications across many clusters from a single definition, which is a core advanced GitOps multi-cluster pattern. Option B is correct because GitOps-driven traffic management with a service mesh (for example Istio or Linkerd) stores routing, failover, and canary rules declaratively in Git and reconciles them across clusters, enabling progressive delivery and cross-cluster traffic control. Option C is correct because Policy-as-Code for multi-cluster compliance uses tools like Open Policy Agent/Gatekeeper or Kyverno to enforce and audit policies consistently across clusters, with policy definitions versioned and reconciled via GitOps.

Option D is not an advanced multi-cluster pattern; consolidating everything into a single cluster contradicts the goal of multi-cluster management and creates a single point of failure. Option E is not GitOps at all, since manual shell scripts for cluster provisioning are imperative, non-declarative, and not continuously reconciled from a Git source of truth.

Exam trap

The trap is selecting options that are either too basic (single cluster) or anti-GitOps (manual scripts), mistaking them for advanced patterns; the exam expects you to recognize that advanced patterns involve automation, scalability, and declarative configuration.

Full explanation →

MCQmedium

In the context of GitOps, what is meant by 'Pull-based' architecture?

A.The cluster agent proactively pulls configurations from the repository.

B.The repository pulls changes from the cluster.

C.The cluster is pulled into the development network.

D.Developers push code to the cluster API.

E.External systems pull logs from the cluster.

AnswerA

A controller inside the cluster continuously reconciles desired state from the Git repository, pulling changes rather than receiving pushed CI/CD instructions. This satisfies the stem's pull-based constraint: the agent initiates retrieval, so credentials stay in-cluster and drift is auto-corrected.

Why this answer

In a pull-based GitOps architecture, an agent running inside the cluster (such as Argo CD or Flux) continuously monitors the Git repository for changes and pulls the desired state, applying it to the cluster. This is in contrast to push-based models where external systems push changes into the cluster. The cluster agent proactively pulls configurations, ensuring the cluster state converges to the declared state in Git.

Exam trap

The trap here is confusing pull-based with push-based models; candidates might think that the repository pulls from the cluster or that developers push to the cluster, but in GitOps, the cluster pulls from the repository.

How to eliminate wrong answers

Option B is wrong because it describes the repository pulling changes from the cluster, which is the opposite of how GitOps works; Git is the source of truth, not the cluster. Option C is wrong because it refers to a physical network concept, not GitOps architecture. Option D is wrong because developers pushing code to the cluster API describes a push-based model, not pull-based.

Option E is wrong because pulling logs is unrelated to configuration management in GitOps.

Full explanation →

MCQeasy

In the context of GitOps, what is the primary role of the 'Source of Truth'?

A.To store the database backups for the application.

B.To host the container images used by the applications.

C.To act as the runtime environment where pods are scheduled.

D.To serve as the definitive, version-controlled repository for the system's desired configuration.

AnswerD

A version-controlled repository stores the desired configuration declaratively, giving GitOps its authoritative baseline. Argo CD or Flux continuously reconcile live cluster state against this repository, so any drift triggers correction. This satisfies the stem's requirement for a definitive source of truth, since every change is auditable, reviewable and revertible through Git history.

Why this answer

In GitOps, the Source of Truth is the Git repository that holds the declarative, version-controlled desired state of the entire system. All deployments and reconciliations are driven from this repository, making it the authoritative reference for what the infrastructure and applications should look like. Any divergence between the cluster and Git is treated as drift to be corrected.

Exam trap

CGOA often tests whether candidates confuse the Source of Truth (Git repo with desired config) with other storage locations like registries or backup systems, catching those who pick a plausible but incorrect data store.

How to eliminate wrong answers

Option A is wrong because database backups are stored in backup systems or object storage, not in the GitOps source of truth. Option B is wrong because container images are hosted in a container registry; Git stores manifests that reference those images, not the images themselves. Option C is wrong because the runtime environment where pods are scheduled is the Kubernetes cluster, which is the target of GitOps, not the source of truth.

Full explanation →

Multi-Selecthard

Which THREE actions occur when a GitOps controller detects drift?

Select 3 answers

A.The controller generates an alert/notification.

B.The controller automatically deletes the cluster.

C.The controller marks the resource as 'OutOfSync'.

D.The controller applies the desired state from Git to the cluster.

E.The controller pushes the manual changes back to Git.

AnswersA, C, D

On detecting divergence between Git and the cluster, the controller emits an alert or notification through configured channels such as Slack or webhooks. This surfaces drift to operators, satisfying the stem's requirement for an action occurring on drift detection.

Why this answer

When a GitOps controller (e.g., Argo CD or Flux) detects that live cluster state diverges from the desired state stored in Git, it flags the affected resource as 'OutOfSync' (option C), which is the standard status used by tools like Argo CD to indicate drift between the Git manifest and the running object. It also generates an alert or notification (option A) so operators are informed of the drift, typically via webhooks, Slack, or email integrations. Finally, the controller reconciles by applying the desired state from Git to the cluster (option D), overwriting the manual change to restore the declared configuration.

Option B is wrong because no GitOps controller deletes the entire cluster on drift; that is not a defined reconciliation behavior. Option E is wrong because GitOps is one-directional from Git to the cluster — the controller does not push manual cluster changes back into Git, as Git remains the single source of truth.

Exam trap

CGOA often tests the directionality of GitOps — candidates who pick 'push changes back to Git' confuse GitOps with bidirectional sync tools like Terraform Cloud or configuration drift detectors that only report.

Full explanation →

MCQmedium

A platform team manages 50 Kubernetes clusters using GitOps. They need to ensure that an emergency rollback of an application across all clusters can be executed cleanly and audited effectively. What is the standard GitOps mechanism to achieve this rollback?

A.Execute 'helm rollback' on each individual cluster CLI in parallel.

B.Delete the target namespace in each cluster and let the API server re-download the manifest from cache.

C.Revert the bad commit in the Git repository using 'git revert' and merge the change.

D.Power down the GitOps controller pods so the clusters automatically default to their initial factory settings.

AnswerC

Reverting the offending commit restores the previous desired state in Git, which the GitOps operator then reconciles across all 50 clusters. Because the rollback is itself a Git commit, it is versioned and auditable, satisfying the clean, auditable rollback constraint.

Why this answer

In GitOps, the desired state is stored in Git, so rolling back an application is done by reverting the bad commit in Git and merging it. The GitOps controller then reconciles the clusters to the reverted state, providing a clean, auditable rollback across all clusters.

Exam trap

The trap is choosing imperative, cluster-specific rollback methods (helm rollback, namespace deletion) instead of the Git-centric revert that provides auditability and consistency across all clusters.

How to eliminate wrong answers

Option A is wrong because executing 'helm rollback' on each cluster CLI is an imperative, manual process that is not auditable in Git and does not scale across 50 clusters. Option B is wrong because deleting a namespace and relying on the API server to re-download from cache is not a GitOps mechanism and would cause downtime and inconsistency. Option D is wrong because powering down GitOps controllers does not revert to factory settings; it simply stops reconciliation, leaving clusters in their current state.

Full explanation →

Multi-Selecthard

Which THREE of these are valid methods for handling configuration differences across environments (e.g., Dev vs Prod)?

Select 3 answers

A.Using separate directories for each environment's manifests.

B.Using Helm values files for different environments.

C.Manually SSHing into nodes to run sed.

D.Hardcoding every environment in one massive file.

E.Using Kustomize overlays.

AnswersA, B, E

Separate directories per environment keep each environment's manifests isolated within one repository. Overlays or path-scoped sync policies then target the correct folder, so Dev and Prod values never overwrite each other while sharing common base definitions.

Why this answer

Option A is correct because maintaining separate directories per environment (e.g., overlays/dev, overlays/prod or manifests/dev, manifests/prod) is a standard GitOps-friendly pattern that keeps environment-specific manifests isolated and version-controlled. Option B is correct because Helm values files (e.g., values-dev.yaml, values-prod.yaml) let you override chart parameters per environment via helm install -f values-prod.yaml, cleanly separating configuration from templated manifests. Option E is correct because Kustomize overlays (kustomization.yaml with bases and overlays) are purpose-built for patching a common base with environment-specific changes such as replicas, image tags, or resource limits.

Option C is not a valid method because manually SSHing into nodes to run sed is imperative, unversioned, and unreproducible, causing configuration drift. Option D is not valid because hardcoding every environment into one massive file creates tight coupling, raises error risk, and defeats the separation-of-concerns that these declarative tools provide.

Exam trap

CGOA often tests the misconception that imperative methods (SSH + sed) or monolithic files are acceptable for environment differences, when only declarative, layered approaches (directories, Helm values, Kustomize overlays) are GitOps-compliant.

Full explanation →

MCQmedium

An application is configured with 'Automated Sync'. What happens when a developer merges a change to the main branch?

A.The operator waits for a manual override

B.The operator deletes the application

C.The cluster crashes

D.The operator pulls the new state and updates the cluster

AnswerD

With Automated Sync enabled, the operator detects the new commit, pulls the updated desired state from Git, and applies it to the cluster without manual intervention. The merge itself triggers convergence, satisfying the automated synchronisation constraint.

Why this answer

With Automated Sync enabled, the GitOps operator continuously reconciles the desired state in Git with the live cluster state. When a developer merges a change to the main branch, the operator detects the new commit during its next reconciliation cycle, pulls the updated manifests, and applies them to the cluster automatically. This is the core value proposition of GitOps: merge to deploy, with no manual intervention required.

Exam trap

CGOA often tests the behaviour of Automated Sync versus Manual Sync, and candidates may incorrectly assume that Automated Sync still requires some approval or that it only applies to certain resource types — the trap is overcomplicating a straightforward auto-apply mechanism.

How to eliminate wrong answers

Option A is wrong because waiting for a manual override describes Manual sync policy, not Automated — Automated sync proceeds without human approval. Option B is wrong because merging a change does not cause the operator to delete the application; deletion would only occur if the application manifest itself was removed and pruning was enabled. Option C is wrong because a merge triggering a cluster crash is not a normal or expected behaviour; the operator applies changes gracefully and Kubernetes handles rolling updates.

Full explanation →

MCQeasy

Which action should a developer take to deploy a new version of an application in a GitOps-based workflow?

A.Wait for the automated CI/CD tool to trigger a redeployment.

B.Submit a pull request to the Git repository containing the configuration update.

C.Run 'kubectl apply' from their local machine.

D.Log into the Argo CD dashboard and click 'Deploy'.

AnswerB

GitOps treats Git as the single source of truth, so the only sanctioned change path is a pull request updating the desired-state manifests. Merging triggers the operator to reconcile the cluster, satisfying the declarative workflow rather than pushing directly with kubectl.

Why this answer

In a GitOps workflow, Git is the single source of truth, so any change to application state — including a new version — must be expressed as a commit or pull request to the configuration repository. The CD controller then detects the change and reconciles the cluster. This makes the PR the correct deployment trigger, providing review, audit trail, and rollback via Git history.

Exam trap

CGOA often tests the misconception that clicking Deploy in the Argo CD UI or running kubectl apply is equivalent to a GitOps deployment, when only a Git commit/PR produces a durable, reconciled change.

How to eliminate wrong answers

Option A is wrong because waiting for an automated CI/CD tool to trigger a redeployment describes a push-based pipeline, not GitOps — in GitOps the developer initiates the change via Git, not by waiting on a pipeline. Option C is wrong because running kubectl apply from a local machine bypasses Git entirely, creating drift that the GitOps controller will revert, and it destroys the audit trail. Option D is wrong because clicking Deploy in the Argo CD dashboard performs an out-of-band sync that is not persisted to Git, so the change is not durable or reviewable.

Full explanation →

MCQhard

You are using Argo CD to manage a production application. A developer accidentally commits a change that sets the replica count to zero, and the change is merged to the main branch. You want to prevent this from happening again without blocking all changes to the repository. Which GitOps pattern should you implement?

A.Implement a policy-as-code admission controller that rejects manifests with a replica count of zero in production.

B.Enable Argo CD's auto-sync with self-heal and set a minimum replica count in the Application spec.

C.Use Argo CD's sync waves to order the deployment so that the replica count is applied last.

D.Configure a pre-sync hook that runs a script to check the replica count and fails the sync if it is zero.

AnswerA

A policy-as-code admission controller, such as OPA Gatekeeper or Kyverno, can validate manifests before they are applied. By defining a policy that rejects replica counts of zero in production namespaces, you prevent the bad state from being reconciled. This pattern enforces guardrails without blocking all repository changes, aligning with GitOps security practices.

Why this answer

Policy-as-code admission controllers enforce rules at admission time, preventing invalid manifests from being applied. A policy that rejects replica counts of zero in production directly addresses the scenario and acts as a guardrail. This pattern is a core GitOps practice for ensuring compliance and preventing misconfigurations without hindering normal development.

Exam trap

The trap here is thinking that Argo CD's sync features can enforce value constraints, but they only control timing and reconciliation, not validation.

Full explanation →

MCQhard

You are debugging a flux-system reconciliation loop. You notice the Kustomization is stuck in 'Retrying'. What command shows the current status and reason for the failure?

A.flux get kustomizations

B.flux logs

C.kubectl describe kustomization

D.flux wait

AnswerA

The flux get kustomizations command reports each Kustomization's readiness status and the underlying error message, exposing why reconciliation is retrying. It satisfies the need to inspect current state and failure reason without digging through controller logs.

Why this answer

`flux get kustomizations` is the canonical Flux CLI command that lists every Kustomization with its READY state, STATUS message, and last-applied revision, and when a Kustomization is stuck in 'Retrying' the STATUS column shows the exact error (e.g., a failed apply, a missing dependency, or a source-not-ready condition). It queries the Flux CRDs directly and is the fastest way to see the reconciliation reason without digging into controller logs.

Exam trap

CGOA often tests the difference between Flux-native commands (`flux get`, `flux logs`, `flux reconcile`) and generic kubectl commands — the trap is choosing `kubectl describe` or a non-existent `flux wait` instead of the idiomatic `flux get kustomizations`.

How to eliminate wrong answers

Option B is wrong because `flux logs` streams controller logs across all Flux controllers and is useful for deep debugging, but it does not give a per-Kustomization status summary — you would have to grep and correlate log lines manually. Option C is wrong because `kubectl describe kustomization` is not a valid command: Kustomization is a Flux CRD, and while `kubectl describe kustomization <name>` can work if the CRD is installed, it is not the idiomatic Flux command and does not surface the same concise status/reason view; the exam expects the Flux-native CLI. Option D is wrong because `flux wait` is not a real Flux subcommand — there is no such command in the Flux CLI, so it cannot report status.

Full explanation →

MCQhard

A platform engineer wants to configure an application state declaratively. They write an imperative script containing commands like 'kubectl scale deployment --replicas=5' and push this script into a Git repository for execution by a cron job. Why does this approach fail to satisfy the core GitOps principle of 'Declarative Desired State'?

A.The state is defined as a series of execution steps rather than a static description of the target system configuration.

B.GitOps tools only support JSON files and reject any YAML or shell-based configurations.

C.Cron jobs running in Kubernetes cannot execute kubectl commands against the internal API server.

D.Imperative scripts cannot be stored in Git repositories due to file permission limitations.

AnswerA

The script records imperative execution steps, not a static description of the target configuration. GitOps requires the repository to hold the desired end state, which an agent continuously reconciles against live reality. A sequence of commands such as `kubectl scale` cannot be diffed or reconciled, so drift detection and automated convergence become impossible.

Why this answer

The core GitOps principle of 'Declarative Desired State' requires that the system's target configuration be described as a static, declarative specification (e.g., YAML manifests) rather than a series of imperative commands. An imperative script like 'kubectl scale deployment --replicas=5' defines actions to execute, not the desired end state, so it fails to satisfy this principle.

Exam trap

CGOA often tests the distinction between declarative and imperative approaches, and candidates may incorrectly believe that any script stored in Git qualifies as GitOps, missing the requirement for a static desired state description.

How to eliminate wrong answers

Option B is wrong because GitOps tools support YAML and JSON; they do not reject YAML or shell-based configurations outright, though shell scripts are not declarative. Option C is wrong because cron jobs in Kubernetes can execute kubectl commands if they have the necessary RBAC permissions and network access to the API server. Option D is wrong because imperative scripts can be stored in Git repositories; there are no file permission limitations preventing this.

Full explanation →

MCQhard

You have a Git repository that contains multiple Kustomizations. You want Flux to update all of them based on a single trigger. How should you structure the repository?

A.Using one Git repo per application

B.Disabling Kustomize

C.Using a base directory and multiple overlays

D.Combining all manifests into one large file

AnswerC

A base directory holds shared manifests, while overlays reference it and patch per-environment values; a single Flux Kustomization pointed at the overlays path triggers all of them. This satisfies the stem's single-trigger requirement across multiple Kustomizations.

Why this answer

Using a base directory and multiple overlays is the correct approach because Kustomize's base/overlay pattern allows a single Git repository to contain multiple Kustomizations that share common resources. When Flux detects a change in the repository, it can trigger reconciliation for all Kustomizations that reference the same base or overlays, enabling a single trigger to update all of them. This structure promotes DRY principles and simplifies management of multiple environments or variants from one source of truth.

Exam trap

CGOA often tests the misconception that each application or Kustomization requires a separate Git repository, but the exam expects knowledge of Kustomize's base/overlay pattern for efficient multi-Kustomization management from a single repo.

How to eliminate wrong answers

Option A is wrong because using one Git repo per application would require multiple repositories, each with its own trigger, defeating the goal of a single trigger for all Kustomizations. Option B is wrong because disabling Kustomize removes the ability to use Kustomizations altogether, which are the very resources that need to be updated. Option D is wrong because combining all manifests into one large file eliminates the modularity and separation provided by Kustomizations, making it impossible to manage them individually and likely causing conflicts or maintenance issues.

Full explanation →

MCQhard

When configuring an App-of-Apps pattern, which field in the 'Application' manifest controls the order in which child applications are deployed?

A.argocd.argoproj.io/sync-wave

B.spec.project

C.spec.syncPolicy.automated.prune

D.spec.source.targetRevision

AnswerA

Sync-wave annotations on child Applications make Argo CD apply them in ascending wave order, so lower-numbered waves finish before higher ones begin. This directly satisfies the stem's requirement to control deployment ordering within the App-of-Apps pattern.

Why this answer

In the App-of-Apps pattern, the argocd.argoproj.io/sync-wave annotation on each child Application controls the order in which Argo CD applies them. Argo CD processes resources in ascending wave order (negative waves first, then zero, then positive), waiting for each wave to become healthy before proceeding to the next, which lets you sequence dependencies such as CRDs before the operators that use them.

Exam trap

CGOA often tests whether candidates know that ordering in App-of-Apps is controlled by the sync-wave annotation rather than by any spec field, so candidates who see 'order' and 'Application manifest' frequently pick spec.project or spec.syncPolicy instead of the annotation.

How to eliminate wrong answers

Option B is wrong because spec.project designates the AppProject that governs RBAC and permitted source/destination repositories; it has no effect on deployment ordering. Option C is wrong because spec.syncPolicy.automated.prune controls whether resources removed from Git are deleted from the cluster during automated sync, not the order of deployment. Option D is wrong because spec.source.targetRevision specifies the Git revision (branch, tag, or commit) to deploy from, which affects what is deployed, not the sequence in which applications are applied.

Full explanation →

100

MCQhard

A company uses Terraform for IaC and Argo CD for application delivery. How should they manage the dependency between infrastructure provisioning and app deployment to ensure GitOps consistency?

A.Use Crossplane to represent infrastructure as Kubernetes objects, managing both IaC and apps via GitOps.

B.Execute Terraform via a CI job that triggers Argo CD after completion.

C.Manually trigger Terraform runs before pushing new app manifests to Git.

D.Embed Terraform binary execution within a K8s deployment container.

AnswerA

Crossplane exposes infrastructure as Kubernetes custom resources, so Argo CD reconciles both infrastructure and applications from Git using one control plane. This satisfies the dependency requirement by letting sync waves and health checks order provisioning before deployment.

Why this answer

Crossplane extends Kubernetes with CRDs so infrastructure (cloud resources, databases, networks) is represented as Kubernetes objects, meaning Argo CD can reconcile both infrastructure and application manifests from Git using the same GitOps control loop. This eliminates the ordering problem because Argo CD's sync waves and health checks can sequence infrastructure readiness before dependent apps deploy. The other options break GitOps consistency by introducing imperative, out-of-band steps.

Exam trap

CGOA often tests the misconception that wrapping Terraform in a CI job and calling Argo CD afterwards is 'GitOps' — it is not, because the infrastructure lifecycle remains outside the reconciliation loop.

How to eliminate wrong answers

Option B is wrong because triggering Argo CD from a CI job after Terraform completes makes the pipeline imperative and out-of-band — Argo CD's reconciliation loop no longer owns the full desired state, and drift between Terraform state and Git is invisible to GitOps. Option C is wrong because manual Terraform runs are not declarative or auditable, defeating the entire purpose of GitOps and introducing human error and drift. Option D is wrong because running the Terraform binary inside a Kubernetes container is an anti-pattern — Terraform state management, credentials, and provider plugins are not designed for in-cluster execution, and it still doesn't give Argo CD visibility into infrastructure state.

Full explanation →

101

MCQhard

Your organization requires an audit trail of all changes to infrastructure. Why is GitOps superior to imperative 'kubectl' commands for this?

A.Kubectl allows editing the live state without record.

B.Git is faster than kubectl for large clusters.

C.The cluster automatically emails admins when kubectl is used.

D.Git provides a permanent, immutable, and auditable history of who made what change and when.

AnswerD

Every Git commit records author, timestamp and diff, producing an immutable history that cannot be silently altered. Imperative kubectl commands leave no equivalent provenance, so GitOps satisfies the audit requirement by making each infrastructure change attributable and reviewable.

Why this answer

GitOps uses Git as the single source of truth, so every change is a commit with author, timestamp, and diff. This creates a permanent, immutable, and auditable history of who changed what and when, which imperative kubectl commands do not provide.

Exam trap

The trap is focusing on operational speed or automation benefits instead of the specific auditability advantage that Git's commit history provides.

How to eliminate wrong answers

Option A is wrong because while kubectl can edit live state without a record, that is a weakness of imperative commands, not a reason GitOps is superior; the question asks why GitOps is superior, and the correct answer is about Git's audit trail. Option B is wrong because Git is not inherently faster than kubectl for large clusters; speed is not the reason for audit superiority. Option C is wrong because the cluster does not automatically email admins when kubectl is used; that is not a feature of Kubernetes or GitOps.

Full explanation →

102

MCQmedium

When implementing a CI/CD pipeline for GitOps, how should you handle image tag updates?

A.Having the CD operator pull the 'latest' tag directly from the registry.

B.Manually updating the YAML file with the new image tag and committing to Git.

C.Triggering a shell script to update the cluster state directly from the CI pipeline.

D.Using an automated agent that detects new images and commits the tag change back to the Git repo.

AnswerD

An automated agent watches the registry for new image digests and commits the updated tag to the Git repository, so the declared state stays authoritative. This satisfies GitOps reconciliation: the pipeline never pushes directly to the cluster, and Argo CD or Flux deploys the committed change.

Why this answer

In GitOps, Git is the single source of truth for declarative infrastructure and application state. An automated agent (such as Argo CD Image Updater or Flux's image-reflector/image-automation controllers) watches the container registry for new image digests/tags, then writes the updated tag back into the Git manifest and commits it. The CD operator then reconciles the cluster to match the newly committed state, preserving the audit trail and rollback capability that GitOps requires.

Exam trap

CGOA often tests the misconception that GitOps allows the CD operator to pull images directly from the registry or that CI can push state to the cluster — both violate the pull-based, Git-as-source-of-truth model.

How to eliminate wrong answers

Option A is wrong because pulling the 'latest' tag directly from the registry bypasses Git entirely — the deployed image is no longer declared in Git, breaking the single-source-of-truth model and making rollbacks and audit trails impossible. Option B is wrong because manual YAML edits and commits do not scale, are error-prone, and defeat the purpose of CI/CD automation, even though they technically respect GitOps principles. Option C is wrong because a shell script mutating cluster state directly from the CI pipeline is imperative push-based deployment, the exact anti-pattern GitOps replaces with pull-based reconciliation.

Full explanation →

103

Multi-Selecthard

Which THREE activities are part of the 'Automated Pull-Based Reconciliation' process?

Select 3 answers

A.Applying updates to the cluster API.

B.Sending a push notification to developers.

C.Downloading updated manifest files.

D.Polling the Git repository for changes.

E.Compiling binaries on the local cluster node.

AnswersA, C, D

Reconciliation closes the loop by pushing the desired state onto the cluster's API server, creating or amending live objects until actual state matches Git. Applying updates to the cluster API is therefore the write-back step that completes automated pull-based reconciliation.

Why this answer

In the Automated Pull-Based Reconciliation process (as used by GitOps tools like Argo CD or Flux), the agent continuously polls the Git repository for changes (D), which is the defining 'pull' behavior that detects new desired state. Once a change is detected, it downloads the updated manifest files (C) from Git to obtain the declared configuration. The agent then applies those updates to the cluster API (A), reconciling the live state with the desired state stored in Git.

Option B is incorrect because push notifications to developers are not part of the reconciliation loop — reconciliation is about syncing cluster state, not alerting humans. Option E is incorrect because compiling binaries on the local cluster node is a build/CI activity, not part of pulling and applying manifests during reconciliation.

Exam trap

CGOA often tests the confusion between push-based CI/CD (where the pipeline pushes to the cluster) and pull-based GitOps (where the cluster pulls from Git), so candidates mistakenly select push-notification or build-related options.

Full explanation →

104

MCQmedium

Which of the following is a potential downside of using a 'Pull' model?

A.It requires public IP addresses

B.It requires maintaining an operator within the cluster

C.It is slower than pushing

D.It creates a security hole

AnswerB

A pull-based GitOps model requires a continuously running operator inside the cluster to poll the Git repository and reconcile desired state. This satisfies the stem's constraint by naming the operational overhead: the agent itself consumes cluster resources and must be maintained, patched and monitored, unlike a push model where an external pipeline applies changes.

Why this answer

In a Pull model, the GitOps agent (operator) runs inside the cluster and continuously pulls desired state from Git. This means an operator must be deployed, maintained, upgraded, and monitored within each cluster, adding operational overhead. The agent also needs RBAC permissions to apply changes, and its lifecycle must be managed alongside the workloads it controls.

Exam trap

CGOA often tests the misconception that Pull is inherently slower or less secure than Push, when in fact Pull is typically more secure but requires maintaining an in-cluster operator.

How to eliminate wrong answers

Option A is wrong because the Pull model actually avoids requiring public IP addresses on the cluster — the agent initiates outbound connections to Git, which is a security advantage, not a downside. Option C is wrong because the Pull model is not inherently slower than push; reconciliation latency depends on polling intervals and webhook configuration, and pull can be near-instant with webhooks. Option D is wrong because the Pull model is generally considered more secure than push, since it does not require exposing cluster credentials or inbound access to external CI systems.

Full explanation →

105

Multi-Selecthard

Which TWO scenarios represent 'drift' in a GitOps environment?

Select 2 answers

A.A developer manually modifies a Service load balancer IP.

B.A cluster administrator adds an annotation to a Pod using kubectl.

C.A developer submits a valid Pull Request.

D.The controller logs an error about connectivity.

E.The GitOps controller successfully updates a deployment.

AnswersA, B

GitOps treats Git as the single source of truth, so the live Service spec no longer matches the declared manifest. Changing the load balancer IP directly via the API bypasses the reconciliation pipeline, producing configuration drift that the GitOps agent must detect and revert.

Why this answer

Drift in GitOps means the live cluster state diverges from the desired state declared in Git. Option A is correct because manually changing a Service's load balancer IP via kubectl/cloud console alters the running resource outside of Git, so the cluster no longer matches the manifest and the GitOps controller would detect and reconcile that difference. Option B is correct because adding an annotation to a Pod with kubectl is an out-of-band manual mutation of a live object, which is exactly the kind of unauthorized change that constitutes drift.

Option C does not represent drift: a valid Pull Request is the normal Git-based change workflow, and once merged the desired state is updated intentionally. Option D is not drift but an operational/connectivity error in the controller. Option E is not drift but successful reconciliation, where the controller brings the cluster into alignment with Git.

Exam trap

CGOA often tests whether candidates can distinguish out-of-band cluster mutations (drift) from legitimate Git workflow actions and controller-driven reconciliation, luring them toward answers that describe normal operations.

Full explanation →

106

MCQmedium

You are using OPA Gatekeeper with GitOps. You want to prevent any deployment that does not have an 'owner' label. Where should this policy be applied to ensure it is enforced for all GitOps-driven changes?

A.Git pre-receive hook

B.Flux Source Controller

C.Validating Admission Webhook

D.ArgoCD AppProject

AnswerC

Gatekeeper registers as a Validating Admission Webhook, so the API server evaluates every create and update against the ConstraintTemplate before persistence. This intercepts all GitOps-driven changes at admission time, blocking any Deployment lacking the required owner label regardless of which controller applies it.

Why this answer

OPA Gatekeeper enforces policies through a Validating Admission Webhook registered with the Kubernetes API server, so every create/update request — including those from Flux or ArgoCD — is evaluated before persistence. This guarantees the 'owner' label requirement is enforced regardless of how the manifest reaches the cluster.

Exam trap

The trap is assuming GitOps controllers enforce policy — they apply manifests but do not validate them; only an admission webhook like Gatekeeper (or Kyverno) can block non-compliant resources at the API server.

How to eliminate wrong answers

Option A is wrong because a Git pre-receive hook only validates pushes to the Git server; it cannot see cluster state, cannot enforce on resources created outside Git, and is bypassed by direct kubectl applies or by GitOps controllers reconciling already-merged commits. Option B is wrong because the Flux Source Controller only fetches and packages source artifacts from Git/Helm/OCI — it does not evaluate admission policies. Option D is wrong because an ArgoCD AppProject scopes which repos, clusters, and namespaces an Application may target; it is an ArgoCD RBAC/scoping construct, not a policy engine, and it does not apply to Flux or to non-ArgoCD changes.

Full explanation →

107

Multi-Selecteasy

Which TWO of the following are core components of a mature GitOps-based DevSecOps practice?

Select 2 answers

A.Using manual SSH access for emergency production troubleshooting.

B.Ensuring all developers have cluster-admin privileges for rapid debugging.

C.Relying primarily on graphical user interfaces for cluster management.

D.Integrating automated security policies (like OPA) into the deployment workflow.

E.Defining infrastructure as code to ensure repeatability.

AnswersD, E

Embedding automated policy checks such as Open Policy Agent into the pipeline enforces security guardrails at deploy time, satisfying the DevSecOps requirement that controls be codified and continuously applied rather than reviewed manually after release.

Why this answer

Option D is correct because a mature GitOps-based DevSecOps practice embeds policy-as-code engines such as Open Policy Agent (OPA) with Gatekeeper into the CI/CD and reconciliation pipeline, so admission and deployment decisions are automatically enforced against security and compliance rules rather than relying on manual review. Option E is correct because GitOps requires the desired state of infrastructure and applications to be declared as code in a Git repository, which makes deployments repeatable, version-controlled, auditable, and continuously reconciled by tools like Argo CD or Flux. Option A is incorrect because manual SSH access bypasses the declarative Git workflow, breaks auditability and reproducibility, and undermines the principle that changes flow through Git.

Option B is incorrect because granting all developers cluster-admin privileges violates least privilege and expands the blast radius of mistakes or compromised credentials. Option C is incorrect because GitOps depends on declarative manifests, CLI tooling, and automated pipelines rather than GUI-driven cluster management, which is not a core component of the practice.

Exam trap

The trap is selecting seemingly convenient but insecure practices (SSH, cluster-admin, GUI) as 'core' components; the exam tests whether you recognize that GitOps and DevSecOps prioritize automation, least privilege, and declarative code over manual intervention.

Full explanation →

108

Multi-Selectmedium

Which TWO of the following are primary benefits of storing the entire desired state of a system in a versioned Git repository?

Select 2 answers

A.Comprehensive audit trail of all configuration changes

B.Automatic hardware repair

C.Simplified recovery to a previous known-good state

D.High-availability of the Git server

E.Automatic scaling of cluster nodes

AnswersA, C

Every commit records who changed what and when, giving a complete, tamper-evident history of desired state. This satisfies the auditability benefit of versioned Git storage, since the commit log itself becomes the authoritative record of all configuration changes.

Why this answer

Option A is correct because committing the full desired state to Git records every change with author, timestamp, and diff, producing a comprehensive, immutable audit trail of all configuration changes. Option C is correct because Git's commit history lets you check out or revert to any earlier commit, so you can restore a previous known-good desired state quickly and reliably. Options B, D, and E are not benefits of versioning desired state: Git does not perform automatic hardware repair, does not by itself provide high availability of the Git server, and does not automatically scale cluster nodes—those require separate tooling and infrastructure.

Exam trap

CGOA often tests the misconception that version control alone provides operational capabilities like auto-scaling or self-healing, when in fact it only stores the desired state; the actual enforcement requires additional tooling.

Full explanation →

109

MCQmedium

What is the primary function of a 'GitOps Pipeline' versus a 'GitOps Controller'?

A.The pipeline manages the Git state directly.

B.They are the same thing.

C.The controller builds the images.

D.The pipeline prepares the artifacts, while the controller reconciles the state.

AnswerD

The pipeline handles preparation tasks such as building, testing and updating manifests in Git, while the controller continuously watches the repository and reconciles live cluster state to match. This division of labour is the axis the stem asks about.

Why this answer

The primary function of a GitOps Pipeline is to prepare and update artifacts (e.g., build images, update manifests) and commit them to Git, while a GitOps Controller continuously reconciles the desired state from Git with the actual state in the cluster. Thus, the pipeline handles artifact preparation, and the controller ensures the cluster matches Git.

Exam trap

CGOA often tests the confusion between CI pipeline responsibilities and GitOps controller responsibilities, and candidates may think the controller builds images or the pipeline manages cluster state.

How to eliminate wrong answers

Option A is wrong because the pipeline does not manage the Git state directly; it updates Git as part of the CI process, but the controller is responsible for reconciling the state. Option B is wrong because they are distinct components with different roles. Option C is wrong because the controller does not build images; that is typically done by the pipeline or CI system.

Full explanation →

110

Multi-Selectmedium

Which TWO items are typically included in a GitOps repository?

Select 2 answers

A.User password lists.

B.Kustomize overlays or Helm charts.

C.Database backups.

D.Kubernetes manifest files.

E.Application source code.

AnswersB, D

Kustomize overlays and Helm charts belong in a GitOps repository because they declare the desired Kubernetes state as versioned manifests, which the reconciler continuously applies. This satisfies the stem's requirement for items typically included, since both tools template and parameterise deployments per environment without imperative cluster commands.

Why this answer

Option B (Kustomize overlays or Helm charts) is correct because a GitOps repository stores the declarative configuration that defines the desired state of the cluster, and Kustomize overlays and Helm charts are the standard templating/packaging tools used to express environment-specific Kubernetes configuration. Option D (Kubernetes manifest files) is correct because GitOps relies on version-controlled YAML manifests (Deployments, Services, ConfigMaps, etc.) as the single source of truth that an agent such as Argo CD or Flux continuously reconciles against the live cluster. Option A (user password lists) does not belong because secrets must never be committed in plaintext to Git; they are handled via sealed secrets, SOPS, or external secret managers.

Option C (database backups) does not belong because backups are runtime data artifacts stored in object storage or backup systems, not declarative desired-state configuration. Option E (application source code) does not belong because the application code lives in its own source repository and is built into container images by CI, while the GitOps repo holds only the deployment/configuration manifests.

Exam trap

CGOA often tests the boundary between configuration and other artifacts — the trap is including application source code or secrets in the GitOps repo, when the repo is specifically for declarative deployment configuration like manifests and Helm/Kustomize artifacts.

Full explanation →

111

MCQhard

You are using ArgoCD and need to ensure that a Helm chart is rendered correctly with a specific set of values. Where do you specify these values in the ArgoCD Application resource?

A.spec.syncPolicy.values

B.spec.parameters

C.spec.destination.values

D.spec.source.helm.values

AnswerD

Helm values are supplied under spec.source.helm.values in the ArgoCD Application resource, where the chart's value overrides are declared. ArgoCD passes these to the Helm template rendering, ensuring the chart renders with the specific values required.

Why this answer

In an ArgoCD Application resource, Helm values are specified under spec.source.helm.values, which is the field ArgoCD reads when rendering the chart. This allows you to override chart defaults with a specific set of values. The other paths do not exist in the Application CRD.

Exam trap

CGOA often tests the exact path of Helm values in the Application CRD; candidates confuse spec.source.helm.values with non-existent fields like spec.parameters or spec.syncPolicy.values.

How to eliminate wrong answers

Option A is wrong because spec.syncPolicy controls sync behavior such as automated sync, pruning, and self-heal; it has no values field. Option B is wrong because spec.parameters is not a valid field in the Application spec for Helm values; parameters are used in other contexts like Kustomize or plugin configs. Option C is wrong because spec.destination defines the target cluster and namespace, not Helm values.

Full explanation →

112

Multi-Selecthard

Which THREE of the following represent common symptoms of 'drift' in a GitOps-managed cluster?

Select 3 answers

A.Unexpected changes to resource labels or annotations

B.Manual editing of a ConfigMap via kubectl

C.Successful CI pipeline execution

D.Unauthorized scaling of a deployment

E.Git commit history being too long

AnswersA, B, D

Labels and annotations altered outside Git change resource metadata from the declared desired state, so the cluster no longer matches the repository. Controllers and selectors relying on those labels may misbehave, and reconciliation flags the resources as OutOfSync, confirming drift.

Why this answer

Drift in a GitOps-managed cluster means the live state diverges from the desired state declared in Git, so option A is correct because unexpected changes to resource labels or annotations indicate someone or something modified objects outside the Git workflow, breaking the declared manifest. Option B is correct because manually editing a ConfigMap via kubectl changes the live cluster state directly, bypassing Git as the single source of truth and creating drift that a reconciler like Argo CD or Flux would detect and revert. Option D is correct because unauthorized scaling of a deployment alters the replica count away from the value in Git, a classic drift symptom that reconciliation would flag or correct.

Option C does not belong because a successful CI pipeline execution is a normal build/test outcome and says nothing about live cluster state diverging from Git. Option E does not belong because a long Git commit history is simply normal repository activity and is unrelated to whether the cluster's actual state matches the desired state.

Exam trap

The trap is treating any cluster or pipeline activity as drift — candidates pick 'successful CI' or 'long commit history' because they sound operational, but drift is specifically live-state divergence from Git.

Full explanation →

113

MCQmedium

What happens if the 'revision' in an Argo CD Application points to a branch that does not exist?

A.It will create the branch automatically.

B.It will stop the Argo CD controller.

C.The application will be marked as 'Invalid' or 'Degraded'.

D.It will sync the 'main' branch instead.

AnswerC

Argo CD resolves the target revision against the repository when syncing. If the named branch is absent, resolution fails, so the Application cannot render desired manifests and its status becomes Invalid or Degraded rather than Synced, satisfying the scenario's non-existent branch constraint.

Why this answer

If the revision points to a non-existent branch, Argo CD cannot resolve the desired state, so the Application's sync status becomes Unknown/Invalid and health may show Degraded or Missing. It does not fall back to another branch or create one. The controller continues running; only that Application is affected.

Exam trap

CGOA often tests the misconception that Argo CD will fall back to a default branch or auto-create a missing branch, when it actually surfaces an Invalid/Degraded status without changing Git.

How to eliminate wrong answers

Option A is wrong because Argo CD never creates branches in Git; it is a read-only consumer of the repository. Option B is wrong because a bad revision affects only the Application's reconciliation, not the Argo CD controller process, which keeps managing other Applications. Option D is wrong because Argo CD does not silently substitute main; it reports an error rather than syncing an unintended branch.

Full explanation →

114

MCQmedium

In a GitOps workflow, where does the 'source of truth' reside?

A.In the Git repository.

B.In the application's environment variables.

C.In the Kubernetes etcd database.

D.In the developer's local workstation.

AnswerA

Git stores the declarative desired state, so it is the single source of truth. Agents continuously reconcile live cluster state against that repository, meaning every approved change flows through commits rather than direct cluster edits.

Why this answer

In GitOps, the Git repository is the single source of truth because it declaratively stores the desired state of the entire system — manifests, Helm charts, Kustomize overlays, and configuration. Controllers continuously reconcile the live cluster state against this repository, so any drift or change must be committed to Git first. This makes Git the authoritative record of what should be running.

Exam trap

CGOA often tests the distinction between desired state (Git) and observed state (etcd/cluster), catching candidates who pick etcd because it stores the running configuration.

How to eliminate wrong answers

Option B is wrong because environment variables are runtime inputs consumed by the application, not the declarative desired-state store that GitOps reconciles against. Option C is wrong because etcd holds the current observed state of the cluster, not the intended state — it is the target of reconciliation, not the source of truth. Option D is wrong because a developer's local workstation is ephemeral and unshared; GitOps explicitly removes local machines from the authoritative path by requiring all changes to flow through Git.

Full explanation →

115

MCQmedium

You want to use Helm for your GitOps deployments. Where should the 'values.yaml' file reside for environment-specific overrides?

A.In the Git repository, per environment.

B.In a local machine folder not tracked by Git.

C.In the Argo CD global settings.

D.Inside the container image.

AnswerA

GitOps treats Git as the single source of truth, so environment-specific values.yaml overrides must be committed per environment in the repository. Argo CD then renders the chart against the correct values file for each target environment.

Why this answer

Environment-specific values.yaml overrides must live in Git, organized per environment (e.g., envs/dev/values.yaml, envs/prod/values.yaml), so the GitOps operator can render the chart with the correct values for each target cluster. This keeps Git as the single source of truth and makes environment differences reviewable and auditable.

Exam trap

The trap is thinking values can live in the operator's global config or the image — GitOps requires all desired-state inputs, including values files, to be versioned in Git.

How to eliminate wrong answers

Option B is wrong because a local, untracked folder is invisible to the GitOps operator and breaks reproducibility — no one else can see or review the values. Option C is wrong because Argo CD global settings (argocd-cm) are for platform configuration, not per-application Helm values; values belong with the app in Git. Option D is wrong because baking values into a container image couples configuration to the artifact, prevents per-environment overrides, and violates the separation of build and deploy.

Full explanation →

116

MCQeasy

What is the primary benefit of using a pull-based GitOps operator compared to a push-based CI/CD system?

A.It eliminates the need for container registries.

B.You can use fewer Git branches.

C.The CI system runs faster.

D.The cluster does not need inbound access from the CI pipeline.

AnswerD

In a pull model the operator runs inside the cluster and fetches desired state from Git, so no inbound firewall rule, exposed endpoint or cluster credentials are needed by the external CI pipeline. This satisfies the constraint of reducing the attack surface and avoiding inbound connectivity into the cluster.

Why this answer

In a pull-based GitOps model, the operator runs inside the cluster and continuously pulls the desired state from Git. This means the CI system does not need to connect to the cluster's API server, eliminating the need for inbound access to the cluster from external systems. This improves security by reducing the attack surface.

Exam trap

The trap here is assuming that pull-based GitOps eliminates the need for container registries or that it speeds up CI, when the core benefit is security and network isolation.

How to eliminate wrong answers

Option A is wrong because container registries are still needed to store and retrieve container images; GitOps does not eliminate them. Option B is wrong because the number of Git branches is unrelated to the pull vs push model. Option C is wrong because the speed of the CI system is not the primary benefit; in fact, pull-based may introduce slight delays due to polling intervals.

Full explanation →

117

MCQeasy

Which of the following describes the 'Declarative' aspect of GitOps?

A.Manually clicking buttons in a UI to scale a service.

B.Defining the desired state in a YAML file.

C.Creating a list of commands to run in order.

D.Writing a shell script to upgrade a deployment.

AnswerB

Declarative means the desired end state is expressed as data, typically YAML manifests, rather than imperative commands. The controller continuously reconciles actual state toward that declared specification, which is the defining mechanism separating GitOps from script-driven deployment.

Why this answer

Declarative configuration means you describe the desired end state (what the system should look like) rather than the steps to reach it (how to get there). Defining the desired state in a YAML manifest — e.g., a Deployment with replicas: 3 — is the canonical declarative approach in GitOps, and the controller continuously reconciles actual state to match it.

Exam trap

CGOA often tests the confusion between declarative (desired end state, e.g., YAML spec) and imperative (step-by-step commands or scripts) — candidates pick 'list of commands' or 'shell script' thinking automation equals declarative.

How to eliminate wrong answers

Option A is wrong because manually clicking buttons in a UI is imperative and non-reproducible — it is the opposite of declarative and cannot be version-controlled or audited. Option C is wrong because a list of commands to run in order is imperative/procedural (how to do something), not declarative (what the end state should be). Option D is wrong because a shell script that upgrades a deployment encodes a sequence of steps — it is imperative automation, not a declarative desired-state definition, and it lacks idempotent reconciliation.

Full explanation →

118

MCQmedium

Why do you use a separate repository for application code and application manifests (deployment manifests) in GitOps?

A.It is required by the Kubernetes specification.

B.Because they are written in different languages.

C.To allow different teams to manage code and configuration independently and securely.

D.It makes the CI/CD pipeline run faster.

AnswerC

Separating application code from deployment manifests lets developers commit freely to the code repository while platform or operations teams control the manifest repository. Access controls, review requirements and release cadence can then differ per repository, satisfying the need for independent, secure management.

Why this answer

Separating application code from deployment manifests lets different teams own their respective concerns: developers control code and CI, while platform or ops teams control deployment configuration, environment-specific values, and security policies. This separation also enforces least privilege — developers may not need write access to production manifests, and auditors can review config changes independently of code changes.

Exam trap

CGOA often tests whether candidates understand that repo separation is an organizational and security pattern, not a technical requirement — the trap is picking answers that cite Kubernetes specs or language differences.

How to eliminate wrong answers

Option A is wrong because Kubernetes has no specification requiring separate repositories for code and manifests — it is a GitOps best practice, not a platform mandate. Option B is wrong because the languages used (e.g., Go vs YAML) are irrelevant to repository structure; both can coexist in one repo without technical issue. Option D is wrong because separate repositories do not inherently make CI/CD faster — in fact, they can add coordination overhead, though they improve security and ownership boundaries.

Full explanation →

119

Multi-Selecthard

Which THREE of the following are valid components of the ArgoCD architecture?

Select 3 answers

A.API Server

B.Application Controller

C.Repo Server

D.Source Controller

E.Kustomization Controller

AnswersA, B, C

The API Server is ArgoCD's central gRPC/REST service, handling all UI, CLI and CI/CD interactions. It enforces RBAC, manages application state and delegates Git repository operations to the Repo Server. This satisfies the stem's requirement for a valid architectural component, as it is one of ArgoCD's core services alongside the Application Controller and Redis.

Why this answer

The ArgoCD architecture is composed of three main components: the API Server (A), which exposes the gRPC/REST API used by the Web UI, CLI, and CI systems and handles authentication, RBAC, and application management; the Application Controller (B), which continuously monitors running applications and compares live state against the desired state defined in Git (a Kubernetes controller that performs sync/health assessment); and the Repo Server (C), which maintains a local cache of Git repositories and generates Kubernetes manifests by rendering Helm charts, Kustomize, or plain YAML. Options D (Source Controller) and E (Kustomization Controller) are not ArgoCD components — Source Controller is part of Flux (Flux's source-controller), and Kustomization Controller is also a Flux component (kustomize-controller), so neither belongs to the ArgoCD architecture.

Exam trap

CGOA often tests whether candidates can distinguish ArgoCD's native components from Flux's controllers (source-controller, kustomize-controller, helm-controller), which are commonly mixed into the answer choices as distractors.

Full explanation →

120

MCQhard

During an audit, an organization discovers that a secret was accidentally committed to a Git repository managed by Flux. An engineer deletes the commit containing the secret using 'git push --force' with a rewritten history. Why is this action problematic in a production GitOps environment?

A.Force-pushing history breaks the cryptographic chain of custody and can desynchronize agents expecting immutable, append-only history.

B.Kubernetes secrets created before the force-push are automatically converted into ConfigMaps by the API server.

C.Flux automatically restores deleted Git commits by fetching missing objects from the live cluster memory.

D.Git repositories permanently reject future commits if a force-push is detected by the GitOps operator.

AnswerA

Force-pushing rewrites commit hashes, so Flux's source controller detects a divergent revision rather than a fast-forward, and any agent tracking the original SHA desynchronises. GitOps relies on immutable, append-only history for reconciliation and audit; rewriting it destroys that chain of custody, leaving the secret still recoverable in clones and caches.

Why this answer

Force-pushing a rewritten history in a GitOps environment is problematic because it breaks the append-only, immutable history that GitOps agents rely on for cryptographic chain of custody and consistent reconciliation. Flux CD and similar tools expect the Git history to be immutable; rewriting it can cause agents to become desynchronized, as they may have already reconciled a commit that no longer exists, leading to unpredictable behavior.

Exam trap

CGOA often tests the implications of Git history manipulation in GitOps, and candidates may underestimate the impact of force-push on agent synchronization and audit trails.

How to eliminate wrong answers

Option B is wrong because Kubernetes does not automatically convert Secrets to ConfigMaps based on Git operations; this is a nonsensical claim. Option C is wrong because Flux does not restore deleted Git commits from cluster memory; it only reconciles from the Git repository. Option D is wrong because Git repositories do not permanently reject future commits after a force-push; while force-push is discouraged, it does not cause a permanent ban.

Full explanation →

121

MCQmedium

When migrating to GitOps, why is 'Pull' preferred over 'Push' for CD?

A.It makes the deployment process faster.

B.It removes the need for exposed API server credentials in the CI tool.

C.It eliminates the need for Git.

D.It allows developers to push code directly to production.

AnswerB

Pull-based CD has the in-cluster agent fetch desired state, so the CI tool never holds cluster credentials. This eliminates long-lived, externally exposed API server credentials, directly satisfying the stem's security rationale for preferring Pull over Push.

Why this answer

In a pull-based GitOps model, an in-cluster agent (e.g., Argo CD or Flux) continuously reconciles the desired state from Git with the live cluster, so the CI system never needs direct, credentialed access to the Kubernetes API server. This removes the need to store high-privilege cluster credentials in the CI tool, shrinking the attack surface and eliminating a common source of credential leakage. The cluster itself initiates the connection, so the API server does not need to be exposed to external CI runners.

Exam trap

CGOA often tests the misconception that GitOps pull is about speed or eliminating Git, when the real architectural benefit is removing the need to expose cluster credentials to external CI systems.

How to eliminate wrong answers

Option A is wrong because pull-based delivery is not inherently faster — reconciliation loops add latency compared to a direct push, and speed is not the architectural reason GitOps favors pull. Option C is wrong because Git remains the single source of truth in GitOps; the pull agent reads from Git, so eliminating Git would break the entire model. Option D is wrong because GitOps explicitly forbids developers pushing directly to production — changes flow through Git commits and pull requests, then are reconciled by the agent, preserving review and auditability.

Full explanation →

122

Multi-Selecteasy

Which THREE of the following are benefits of using the App-of-Apps pattern? (Select THREE)

Select 3 answers

A.Centralized management of multiple applications.

B.Elimination of the need for Helm.

C.Simplified visualization of related applications in the UI.

D.Ability to sync all related applications with one click.

E.Automatic promotion of code between environments.

AnswersA, C, D

A root Application points to a directory of child Application manifests, so many applications are declared and governed from one parent resource. This gives a single entry point for managing a fleet of related deployments.

Why this answer

Option A is correct because the App-of-Apps pattern uses a parent Argo CD Application that points to a Git repository containing multiple child Application manifests, giving a single control point to manage many applications declaratively. Option C is correct because Argo CD renders the parent and its child Applications as a hierarchical tree in the UI, making it easy to visualize the relationships and health of related applications. Option D is correct because syncing the parent Application triggers reconciliation of the child Application resources, allowing all related applications to be synced together from one action.

Option B is not correct because App-of-Apps is an Argo CD application organization pattern and does not remove the need for Helm or any other templating/packaging tool. Option E is not correct because App-of-Apps does not perform automatic promotion of code between environments; promotion is handled by separate CI/CD or GitOps promotion workflows.

Exam trap

The trap is attributing unrelated capabilities (eliminating Helm, auto-promoting environments) to App-of-Apps, when its actual benefits are centralized management, visualization, and one-click sync.

Full explanation →

123

Multi-Selectmedium

Which TWO of the following are considered advantages of the GitOps approach?

Select 2 answers

A.Increased reliance on manual CLI interventions.

B.Automatic creation of new business requirements.

C.Improved auditability through version-controlled commits.

D.Simplified rollback of infrastructure configurations.

E.Ability to bypass security protocols.

AnswersC, D

Version-controlled commits create an immutable, timestamped record of every desired-state change, satisfying the auditability constraint. Each commit captures who altered what and when, and Git history preserves the full trail for review or rollback. This traceability exceeds imperative deployment methods, where changes often leave no equivalent declarative record.

Why this answer

Option C is correct because GitOps stores the desired state of infrastructure and applications as declarative manifests in a Git repository, so every change is captured as a version-controlled commit with author, timestamp, and diff history, giving a complete and auditable trail. Option D is correct because since the Git history is the single source of truth, reverting to a previous commit (for example with git revert or git reset) lets the GitOps operator automatically reconcile the cluster back to the prior known-good configuration, making rollbacks simple and reliable. The unmarked options do not belong: A is wrong because GitOps reduces manual CLI interventions by automating reconciliation from Git, B is wrong because GitOps manages infrastructure and deployment state rather than generating business requirements, and E is wrong because GitOps enforces security and policy controls through review and CI checks rather than bypassing them.

Exam trap

The trap is picking options that sound like automation benefits but are actually anti-patterns (manual CLI, bypassing security) — GitOps advantages always reduce manual work and increase control, never the reverse.

Full explanation →

124

Multi-Selecthard

Which THREE factors should be considered when choosing a GitOps controller?

Select 3 answers

A.The color scheme of the controller's UI.

B.The controller's support for multi-cluster deployments.

C.Whether it uses a proprietary language.

D.Compatibility with existing CI/CD pipelines.

E.Built-in integration or compatibility with secret management solutions.

AnswersB, D, E

Multi-cluster support determines whether one controller instance can reconcile many clusters or whether each cluster needs its own agent. In a fleet-scale GitOps deployment this directly affects operational overhead, so the controller's multi-cluster capability is a primary selection factor.

Why this answer

Option B is correct because a GitOps controller's ability to manage multiple clusters (e.g., via Argo CD's cluster registration or Flux's multi-cluster support with Kustomization/HelmRelease resources) is a key architectural factor when you operate more than one Kubernetes cluster. Option D is correct because the controller must integrate with your existing CI/CD pipelines—typically by watching a Git repository that CI tools such as Jenkins, GitLab CI, or GitHub Actions update—so the build-and-deploy workflow remains coherent. Option E is correct because GitOps repositories often contain manifests referencing secrets, so built-in integration or compatibility with secret management solutions (e.g., Sealed Secrets, External Secrets Operator, SOPS, or Vault) is essential for secure, automated reconciliation.

Option A is not a valid factor because UI color scheme is cosmetic and has no bearing on functionality, scalability, or operational fit. Option C is not a valid factor because using a proprietary language is not inherently disqualifying; what matters is whether the controller's configuration format and ecosystem fit your team, and many controllers use standard YAML or established templating rather than a proprietary DSL.

Exam trap

CGOA often tests whether candidates can distinguish functional selection criteria (multi-cluster, CI/CD, secrets) from superficial or irrelevant attributes (UI color, proprietary language) that sound plausible but have no operational impact.

Full explanation →

125

MCQeasy

What is the key difference between Configuration as Code and Infrastructure as Code in the context of GitOps?

A.Configuration as Code is only for databases.

B.Config as Code is always written in YAML.

C.They are the same thing.

D.IaC defines the underlying resources, while Config as Code defines the application-level settings.

AnswerD

Infrastructure as Code provisions the underlying resources—compute, networking, storage—through declarative templates, whereas Configuration as Code manages application-level settings layered on top. This split satisfies the stem's request for the key difference: distinct management scopes, with IaC handling resource provisioning and CaC handling runtime configuration.

Why this answer

Infrastructure as Code (IaC) defines the underlying resources — VMs, networks, clusters, storage — while Configuration as Code defines application-level settings such as environment variables, feature flags, and service configuration. In GitOps, both are stored in Git, but they operate at different layers of the stack.

Exam trap

CGOA often tests whether candidates conflate IaC and Config as Code as synonyms — the exam expects recognition that they operate at different layers (resource provisioning vs. application settings).

How to eliminate wrong answers

Option A is wrong because Configuration as Code applies to any application-level setting, not just databases. Option B is wrong because Config as Code can be expressed in JSON, TOML, HCL, or other formats — YAML is common but not mandatory. Option C is wrong because IaC and Config as Code address different layers: infrastructure provisioning versus application configuration.

Full explanation →

126

MCQhard

What is the most effective approach to handle 'secrets' in GitOps when you require strict compliance that mandates secrets never exist in plain text in the repo?

A.Use an external secret store that injects values into the cluster at runtime.

B.Store secrets in an encrypted cloud storage bucket and manually map them.

C.Use standard Kubernetes secrets and hope for the best.

D.Use Sealed Secrets with a public key in Git.

AnswerA

An external secret store, such as HashiCorp Vault or a cloud secrets manager, keeps plaintext out of Git entirely. The operator injects values into the cluster at runtime, satisfying the compliance mandate that secrets never exist in plain text in the repository.

Why this answer

For strict compliance that mandates secrets never exist in plain text in the repo, the most effective approach is an external secret store (e.g., HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) that injects values into the cluster at runtime via an operator like External Secrets Operator or Secrets Store CSI Driver. The Git repo only contains references (e.g., ExternalSecret CRs), never the secret material itself, satisfying the compliance requirement.

Exam trap

CGOA often tests the distinction between 'encrypted in Git' (Sealed Secrets, SOPS) and 'never in Git at all' (external secret stores) — strict compliance questions specifically want the latter, but candidates often pick Sealed Secrets because it sounds secure.

How to eliminate wrong answers

Option B is wrong because storing secrets in an encrypted cloud bucket and manually mapping them still requires manual intervention and does not integrate with GitOps reconciliation — it also creates a second source of truth outside Git. Option C is wrong because standard Kubernetes Secrets are only base64-encoded, not encrypted, and storing them in Git would put plaintext-equivalent secrets in the repo, directly violating the compliance mandate. Option D is wrong because Sealed Secrets, while better than plain Secrets, still stores encrypted secret material in Git — strict compliance regimes often prohibit any secret material (even encrypted) in the repo, and Sealed Secrets are cluster-specific and cannot be rotated easily.

Full explanation →

127

MCQhard

You are migrating a legacy application deployment process to GitOps. The application requires a specific sequence of database migrations to run before the new container version is deployed. How do you implement this in a GitOps-friendly way?

A.Use a Kubernetes 'Job' resource that runs before the Deployment, and manage dependencies with initContainers or Helm hooks.

B.Add a 'kubectl apply' command to the end of the CI pipeline to execute migrations.

C.Hardcode the migration logic into the application source code to run on startup.

D.Create a manual trigger in the GitOps dashboard to execute the migration after the deployment starts.

E.Configure the GitOps agent to execute a shell script on the node before pulling the image.

AnswerA

A Kubernetes Job runs the migrations to completion before the Deployment rolls out, with initContainers or Helm hooks enforcing ordering. Both are declarative resources committed to Git, so the sequence stays version-controlled and the controller reconciles it without manual intervention.

Why this answer

In GitOps, all changes must be declarative and reconciled from Git. A Kubernetes Job resource (or Helm pre-install/pre-upgrade hook) declared in Git runs the migration as part of the desired state, and initContainers or Helm hooks enforce ordering before the Deployment rolls out. This keeps the migration auditable and reproducible.

Exam trap

CGOA often tests whether candidates understand that GitOps forbids imperative out-of-band actions — any answer involving kubectl apply from CI, manual dashboard triggers, or node-level scripts is a GitOps anti-pattern.

How to eliminate wrong answers

Option B is wrong because running kubectl apply from a CI pipeline bypasses the GitOps reconciliation loop and creates drift between Git and the cluster. Option C is wrong because hardcoding migrations into application startup couples schema changes to app lifecycle, risks race conditions with multiple replicas, and is not declarative. Option D is wrong because manual triggers in a dashboard violate GitOps' principle of Git as the single source of truth and are not reproducible.

Option E is wrong because executing shell scripts on nodes via the GitOps agent is imperative, node-specific, and outside the declarative model.

Full explanation →

128

MCQmedium

Your team is using Flux CD to manage Kubernetes resources. You notice that the application status is 'Suspended'. What is the most likely reason for this state in the context of GitOps principles?

A.The cluster is out of memory

B.A user explicitly set the suspend field to true in the resource manifest

C.The controller is unable to connect to the container registry

D.The Git repository contains syntax errors

AnswerB

Setting the `spec.suspend` field to true in a Flux custom resource deliberately halts reconciliation, so the controller stops applying the desired state and the resource reports 'Suspended'. This directly satisfies the stem's GitOps scenario: the state reflects an intentional operator pause, not a sync failure or drift.

Why this answer

In Flux CD, the 'Suspended' status indicates that the reconciliation of a resource has been manually paused by setting the 'suspend' field to true in the resource manifest (e.g., spec.suspend: true). This is a deliberate action to temporarily halt automated syncs, often for maintenance or debugging. It is not caused by environmental issues like memory or connectivity.

Exam trap

CGOA often tests the confusion between 'Suspended' status and error states like 'Failed' or 'NotReady', leading candidates to choose environmental causes instead of the explicit suspend field.

How to eliminate wrong answers

Option A is wrong because cluster memory exhaustion would cause pod failures or OOM errors, not a 'Suspended' status. Option C is wrong because inability to connect to a container registry would result in image pull errors, not suspension. Option D is wrong because Git repository syntax errors would cause reconciliation failures or error states, not a suspended state.

Full explanation →

129

MCQeasy

Which of these is a primary reason for using Helm charts in a GitOps workflow?

A.Encrypting all traffic

B.Replacing the need for Kubernetes

C.Creating Git commits automatically

D.Templating and packaging complex applications

AnswerD

Helm's chart templating renders parameterised manifests from values files, packaging interdependent Kubernetes resources as one versioned artefact. GitOps stores only declarative state in Git, so this abstraction lets Flux reconcile complex applications without duplicating raw YAML per environment.

Why this answer

Helm charts are used in GitOps workflows primarily for templating and packaging complex applications (D). Helm allows you to define Kubernetes resources as parameterized templates, making it easy to manage and version application configurations in Git. This aligns with GitOps principles where the desired state is stored declaratively in Git and applied automatically.

Exam trap

CGOA often tests the confusion between Helm's role as a package manager and other tools' roles, such as encryption or CI/CD automation, causing candidates to select options that are not primary reasons for using Helm.

How to eliminate wrong answers

Option A is wrong because Helm does not encrypt traffic; encryption is handled by Kubernetes networking, service meshes, or TLS certificates. Option B is wrong because Helm does not replace Kubernetes; it is a package manager that runs on top of Kubernetes. Option C is wrong because Helm does not create Git commits automatically; Git commits are made by developers or CI/CD tools, not by Helm.

Full explanation →

130

MCQmedium

You are performing a Canary deployment using Argo Rollouts. You notice that the analysis template is failing even though the metrics are within range. What is the most common cause of this in a GitOps workflow?

A.The analysis template is missing the 'rollback' flag.

B.The Prometheus metric query does not match the 'args' passed from the Rollout object.

C.The Rollout image version is not updated in the Git repository.

D.The ReplicaSet is failing to scale to the desired state.

AnswerB

Argo Rollouts substitutes the Rollout's args into the AnalysisTemplate's Prometheus query by name. If a placeholder in the query does not exactly match the corresponding arg key, the query renders empty or malformed, so the analysis fails despite healthy metrics.

Why this answer

In Argo Rollouts canary deployments, the AnalysisTemplate defines metrics queries (e.g., Prometheus PromQL) and can accept arguments passed from the Rollout's analysis step. If the query references template variables (like {{args.service-name}}) that don't match the args defined in the Rollout's analysis step, the query fails to render or returns invalid results, causing the analysis to fail even when actual metrics are healthy. This mismatch is the most common GitOps misconfiguration.

Exam trap

CGOA often tests whether candidates can distinguish between analysis failures caused by configuration mismatches (args/query) versus actual metric threshold breaches, causing them to chase metric issues when the real problem is template parameterization.

How to eliminate wrong answers

Option A is wrong because there is no 'rollback' flag in an AnalysisTemplate — rollback behavior is controlled by the Rollout's strategy (e.g., aborting on failure), not a template flag. Option C is wrong because an outdated image version in Git would prevent the new version from deploying at all, not cause analysis failure while metrics are in range. Option D is wrong because ReplicaSet scaling failures are a symptom of resource or scheduling issues, not a cause of analysis template failures when metrics are healthy.

Full explanation →

131

MCQhard

In a GitOps environment, what is the 'Reconciliation Loop' primarily responsible for?

A.Running unit tests on application code

B.Generating new Kubernetes manifests

C.Managing user authentication for the Git provider

D.Continuously ensuring the cluster state matches the Git repository

AnswerD

The reconciliation loop continuously compares the live cluster against the desired state stored in Git and applies corrections whenever they diverge. This ongoing convergence, not a one-time deployment, is what keeps the cluster matching the repository.

Why this answer

The Reconciliation Loop is the core control mechanism in GitOps that continuously compares the desired state declared in Git with the actual live state of the Kubernetes cluster. When a difference (drift) is detected, the loop applies the necessary changes to bring the cluster back into alignment with Git, which is the single source of truth. This continuous, automated convergence is what makes GitOps declarative and self-healing rather than a one-time push deployment.

Exam trap

CGOA often tests whether candidates confuse the reconciliation loop with CI pipeline functions like testing or manifest generation, so the trap is picking an option that describes build-time activity instead of runtime state convergence.

How to eliminate wrong answers

Option A is wrong because running unit tests is a CI pipeline activity performed before code is merged, not a function of the runtime reconciliation controller. Option B is wrong because generating Kubernetes manifests is typically done by developers, Helm, Kustomize, or CI tooling — the reconciliation loop consumes manifests, it does not author them. Option C is wrong because authentication to the Git provider is handled by credential management (SSH keys, tokens, sealed secrets), not by the reconciliation loop, which is concerned with state convergence.

Full explanation →

132

MCQmedium

Why should you avoid using 'latest' as a container image tag in GitOps?

A.It prevents the controller from knowing exactly what version is deployed.

B.It causes the cluster to crash.

C.It's slower to pull.

D.It requires more storage space.

AnswerA

A 'latest' tag is mutable, so the Git manifest no longer records an immutable digest. The GitOps controller cannot detect drift or reconcile deterministically, because the deployed artefact may change without any commit. Pinning a version or digest satisfies the requirement that Git remains the single source of truth for exactly what runs.

Why this answer

The 'latest' tag is mutable — it can point to different image digests over time, so the Git manifest no longer uniquely identifies the running artifact. GitOps controllers like Argo CD and Flux reconcile desired state from Git; if the tag is 'latest', the controller cannot detect drift or guarantee that the deployed image matches the declared version, breaking reproducibility and auditability.

Exam trap

CGOA often tests the misconception that 'latest' is simply a version alias rather than a mutable pointer, leading candidates to focus on performance or storage instead of the loss of declarative traceability.

How to eliminate wrong answers

Option B is wrong because a 'latest' tag does not inherently crash the cluster; it may pull an incompatible or broken image, but that is a consequence of the image content, not the tag itself. Option C is wrong because pull speed depends on image size, layer caching, and registry performance, not on the tag string. Option D is wrong because storage consumption is determined by image layers and their deduplication, not by the tag name.

Full explanation →

133

Multi-Selecteasy

Which TWO of the following are considered 'Anti-Patterns' in a GitOps workflow? (Choose two)

Select 2 answers

A.Storing sensitive secrets as plain text in the Git repository.

B.Using a Git branch to represent a specific environment (e.g., prod vs dev).

C.Applying manual configuration changes directly to the production cluster.

D.Automating the deployment process using a GitOps operator.

E.Storing application manifests in a central repository.

AnswersA, C

Plain-text secrets in Git expose credentials to anyone with repository read access, and Git history retains them permanently. This violates GitOps' security principle that the repository should hold declarative, non-sensitive configuration, making it a recognised anti-pattern.

Why this answer

Option A is correct because committing secrets as plain text in Git exposes credentials to anyone with repository read access and permanently embeds them in Git history, violating GitOps' declarative, auditable, and secure source-of-truth model; secrets should instead be managed with tools like Sealed Secrets, SOPS, or an external secrets manager. Option C is correct because making manual changes directly to the production cluster creates configuration drift from the Git-declared desired state, breaking the core GitOps principle that Git is the single source of truth and that all changes flow through version control and automated reconciliation. Option B is not an anti-pattern; using branches (or directories) per environment is a legitimate, widely used GitOps repository strategy for separating prod and dev configurations.

Option D is not an anti-pattern; automating deployment with a GitOps operator such as Argo CD or Flux is the intended practice, as it continuously reconciles cluster state with Git. Option E is not an anti-pattern; storing application manifests in a central repository is a standard GitOps pattern that provides a single, versioned source of truth for deployments.

Exam trap

CGOA often tests whether candidates can distinguish legitimate GitOps patterns (branch-per-environment, central repos) from true anti-patterns (plain-text secrets, manual cluster edits) — the trap is assuming any manual or branch-based approach is wrong.

Full explanation →

134

MCQhard

In a GitOps pattern, how do you manage a rollback when an application deployment fails?

A.Revert the commit in Git and let the GitOps operator reconcile.

B.Delete the pods and let the operator recreate them.

C.Stop the GitOps operator to prevent it from correcting the state.

D.Run 'kubectl rollout undo' on the deployment.

AnswerA

Git remains the single source of truth, so reverting the offending commit restores the previous desired state and the operator reconciles the cluster back to it. This satisfies the GitOps constraint that rollback is a Git operation, not manual kubectl intervention.

Why this answer

In GitOps, Git is the single source of truth for the desired state of the system. To roll back a failed deployment, you revert the offending commit in Git, which changes the desired state back to the last known good version. The GitOps operator (e.g., Argo CD or Flux) continuously reconciles the cluster to match Git, so it will automatically apply the rollback.

This approach ensures that the rollback is version-controlled, auditable, and consistent with the declarative model.

Exam trap

CGOA often tests the misconception that direct kubectl commands or pod deletions can manage state in a GitOps workflow, but the operator will override any manual changes, so only Git-based actions are effective.

How to eliminate wrong answers

Option B is wrong because deleting pods only triggers a restart of the same failing deployment; the operator will recreate pods from the same faulty manifest, so the failure persists. Option C is wrong because stopping the operator halts reconciliation, leaving the cluster in a drifted state and preventing any automated correction; it does not perform a rollback. Option D is wrong because 'kubectl rollout undo' directly modifies the live cluster, bypassing Git; the GitOps operator will detect the drift and revert the change back to the Git-defined state, undoing the manual rollback.

Full explanation →

135

Multi-Selecthard

Which THREE items should be excluded from a GitOps repository?

Select 3 answers

A.Container images (binaries).

B.Plaintext passwords/API keys.

C.Ephemeral cache files.

D.Rendered Kubernetes YAML.

E.Documentation files.

AnswersA, B, C

Container images are large binaries that bloat repository size and cannot be meaningfully diffed or version-controlled as text. GitOps relies on Git tracking declarative manifests, so images belong in a registry referenced by digest or tag, not committed alongside the desired-state configuration.

Why this answer

Option A (Container images/binaries) is correct because GitOps repositories should hold declarative configuration and source, not large binary artifacts; container images belong in a container registry (e.g., Docker Hub, ECR, GCR) referenced by immutable digest or tag, since storing binaries bloats the repo and breaks Git's text-diff/versioning model. Option B (Plaintext passwords/API keys) is correct because committing secrets exposes them permanently in Git history and violates security best practices; secrets should be managed via a secrets manager (e.g., HashiCorp Vault, AWS Secrets Manager, Sealed Secrets, SOPS) and injected at runtime. Option C (Ephemeral cache files) is correct because transient artifacts like build caches, node_modules, or .terraform directories are machine-generated, non-deterministic, and should be excluded via .gitignore since they are not part of the desired state and cause noisy diffs.

Option D (Rendered Kubernetes YAML) is not excluded because rendered manifests are often exactly what a GitOps tool such as Argo CD or Flux reconciles against the cluster, representing the desired declarative state. Option E (Documentation files) is not excluded because README, runbooks, and architecture docs are valuable, human-readable content that belongs alongside the configuration in the repository.

Exam trap

The trap is that candidates may think rendered YAML should be excluded because it is generated, but in GitOps the rendered YAML often is the desired state; also, some may consider documentation unnecessary, but it is not a security or bloat issue.

Full explanation →

136

MCQhard

An organization separates its GitOps repositories into an application repo and an environment configuration repo. Developers merge frequently into the application repo, while the environment repo pins image digests. A release engineer must promote a tested build from staging to production. Which action aligns with this separation of concerns?

A.Tag the current application repo commit as production and let each cluster's operator resolve the newest matching image automatically.

B.Copy the application manifests from staging directly into the production namespace using kubectl apply.

C.Rebuild the container image in the production pipeline to guarantee the artifact matches the production environment.

D.Open a pull request against the environment repo updating the production image digest to the value validated in staging.

AnswerD

Promotion in this model is a change to the environment repo that records the already-tested artifact by digest. Opening a pull request keeps the change reviewable and auditable, and once merged the operator reconciles production to that exact immutable digest. This preserves separation of concerns: developers own application code, while environment configuration and promotion remain a controlled, declarative change.

Why this answer

When application and environment repositories are separate, promotion is expressed as a reviewed change to the environment repo that updates the pinned image digest to the artifact already validated in staging. This keeps artifacts immutable, preserves the boundary between developer-owned code and environment-owned configuration, and lets the operator reconcile production to an exact, auditable revision. Rebuilding, resolving moving tags, or applying directly with kubectl all break that boundary and the guarantee that production runs the tested bits.

Exam trap

The trap here is treating promotion as a build or deployment step rather than as a declarative configuration change recorded in Git.

Full explanation →

137

MCQmedium

You are auditing a GitOps process. Which of the following is an indicator that the process is NOT truly following GitOps principles?

A.Secrets are encrypted in the Git repo.

B.The cluster automatically reconciles changes pushed to Git.

C.Developers use PRs to propose changes to the environment.

D.An administrator manually updates a Kubernetes Deployment manifest directly on the cluster.

AnswerD

Directly editing a Deployment manifest on the cluster bypasses Git, the declared source of truth, producing drift the reconciler must revert. This out-of-band change breaks the pull-based workflow's audit trail and reproducibility, indicating the process is not genuinely GitOps.

Why this answer

GitOps requires that the Git repository serves as the single source of truth for the desired state of the system, with all changes flowing through Git and being automatically reconciled by an operator. Option D describes a manual, out-of-band change directly to the cluster, which bypasses Git entirely and breaks the declarative, version-controlled workflow. This is a clear violation because the live state can drift from the declared state without any audit trail or reconciliation trigger.

Exam trap

CGOA often tests the misconception that any manual intervention is acceptable as long as Git is used elsewhere, but the exam expects you to recognize that direct cluster modifications violate the core GitOps principle of Git as the single source of truth.

How to eliminate wrong answers

Option A is wrong because encrypting secrets in Git is a recommended practice (e.g., using Sealed Secrets or SOPS) to safely store sensitive data while still adhering to GitOps; it does not indicate a violation. Option B is wrong because automatic reconciliation of Git changes is a core GitOps principle, so it is an indicator of correct implementation, not a failure. Option C is wrong because using pull requests to propose changes is a standard GitOps practice that enforces review and collaboration, aligning with the declarative model.

Full explanation →

138

MCQhard

You notice that your GitOps pipeline is stuck in a loop. What is the most likely cause?

A.The deployment process automatically commits changes back to the same Git branch that triggers the deployment.

B.The cluster is too small.

C.The Git repository contains a circular reference.

D.The container registry is offline.

AnswerA

A reconciliation loop continuously compares desired Git state with live cluster state. If the deployment writes its changes back to the same branch that triggers it, each commit spawns another deployment, which commits again, producing an infinite self-triggering cycle.

Why this answer

A GitOps pipeline loop occurs when the deployment process writes changes back to the same Git branch that triggers the deployment, creating a feedback cycle where each sync generates a new commit that triggers another sync. This is common when tools like Argo CD or Flux are configured to update image tags or manifests in Git as part of the deployment. The fix is to separate the write-back branch or use a different mechanism like image updater with proper filters.

Exam trap

CGOA often tests the misconception that pipeline loops are caused by infrastructure issues (cluster size, registry) rather than by the pipeline writing back to its own trigger branch.

How to eliminate wrong answers

Option B is wrong because cluster size affects capacity and scheduling, not the logic of a sync loop; a small cluster would cause pending pods, not infinite reconciliation. Option C is wrong because Git does not support circular references in the way described; a repository can have symlinks or submodules but that would not cause a deployment loop. Option D is wrong because an offline container registry would cause image pull failures, not a repeating sync loop.

Full explanation →

139

MCQmedium

What is the primary role of a 'GitOps controller'?

A.To watch the repository and reconcile the cluster state

B.To host the container registry

C.To generate user tokens

D.To manage Git branches

AnswerA

A GitOps controller runs inside the cluster, continuously polling the Git repository and comparing it against live resources. When divergence appears, it applies the repository's declared state, satisfying the requirement that the cluster is automatically reconciled to match Git without manual intervention.

Why this answer

A GitOps controller (e.g., Argo CD's application controller or Flux's kustomize-controller) continuously watches the Git repository for the desired state and reconciles the live cluster to match it, detecting and correcting drift. It is the engine that closes the loop between declarative intent in Git and actual cluster state. Without it, GitOps is just version-controlled YAML with no enforcement.

Exam trap

CGOA often tests the controller's core function; candidates may pick 'manage Git branches' because the controller interacts with Git, confusing reading a revision with administering the repository.

How to eliminate wrong answers

Option B is wrong because hosting a container registry is the job of a registry service (Harbor, ECR, GCR, Docker Hub), not a GitOps controller — the controller pulls images indirectly via the workloads it deploys but does not serve them. Option C is wrong because generating user tokens is an authentication/identity function handled by an IdP or Kubernetes service account token machinery, not the GitOps controller. Option D is wrong because managing Git branches is a version-control operation performed by developers or CI tooling; the controller reads a specified branch/revision but does not administer branches.

Full explanation →

140

Multi-Selectmedium

Which TWO aspects of GitOps help ensure 'Continuous Drift Detection'?

Select 2 answers

A.Daily manual audit reports.

B.Forcing all developers to use SSH.

C.Comparing live state with the desired state in Git.

D.Regular polling or event-based monitoring of cluster state.

E.Using a database to store current cluster state.

AnswersC, D

Continuous drift detection relies on the GitOps reconciliation loop repeatedly comparing the live cluster state against the desired state declared in Git. Any divergence triggers correction or alerting, so this comparison is the mechanism that continuously surfaces configuration drift.

Why this answer

Option C is correct because Continuous Drift Detection fundamentally relies on continuously comparing the live state of the cluster against the desired state declared in Git, which is the single source of truth in GitOps; any divergence between the two constitutes drift. Option D is correct because this comparison must happen continuously, which is achieved through regular polling of the cluster or event-based monitoring (e.g., Kubernetes controllers, webhooks, or GitOps agents like Argo CD or Flux reconciling on an interval or on change events). Together, C and D describe the mechanism (compare live vs. desired) and the trigger (continuous polling/events) that make drift detection continuous.

Option A is incorrect because daily manual audit reports are periodic and human-driven, not continuous or automated. Option B is incorrect because mandating SSH for developers is an access-control practice unrelated to drift detection. Option E is incorrect because storing cluster state in a database is not how GitOps detects drift; the desired state lives in Git, and drift is found by comparing it to the live cluster, not by querying a separate database.

Exam trap

CGOA often tests the distinction between the comparison mechanism (live vs. Git) and the trigger mechanism (polling/events) — candidates frequently pick only one and miss that drift detection requires both halves of the reconciliation loop.

Full explanation →

141

Multi-Selectmedium

Which TWO of the following are benefits of using Git as the 'Source of Truth'?

Select 2 answers

A.Clear audit trail of who changed what and when

B.Automated rollback via git revert

C.Automatic removal of unused cloud accounts

D.Increased reliance on manual terminal access

E.Faster CPU performance for applications

AnswersA, B

Every commit records the author, timestamp and diff, giving an immutable audit trail of who changed what and when. This traceability satisfies compliance and review requirements, letting teams correlate cluster state changes back to specific approved commits.

Why this answer

Option A is correct because Git records every commit with author identity, timestamp, and a cryptographic hash of the exact changes, giving an immutable, reviewable history of who changed what and when — the essence of an audit trail for a source of truth. Option B is correct because Git's versioned history lets you undo a bad change deterministically with commands like git revert (which creates a new commit that inverts a prior one) or git reset, enabling reliable rollback to a known-good state. Option C is wrong because Git is a version-control system for code and configuration, not a cloud IAM or account-lifecycle tool; it cannot detect or delete unused cloud accounts.

Option D is wrong because Git reduces reliance on manual terminal access by providing a structured, reviewable workflow (commits, branches, pull requests) rather than encouraging ad-hoc manual changes. Option E is wrong because Git has no bearing on application CPU performance; it manages source history, not runtime compute resources.

Exam trap

CGOA often tests Git's operational benefits — the trap is selecting options that sound like general IT benefits (faster CPU, cloud cleanup) but have no technical connection to Git.

Full explanation →

142

MCQmedium

What is the purpose of 'Image Tagging' in a GitOps workflow?

A.To force the container to restart.

B.To ensure that the exact version of the application is deployed consistently.

C.To track how many users are logged in.

D.To allow the container registry to delete old images.

AnswerB

Image tags pin a deployment manifest to an immutable, specific build version, so the GitOps reconciler deploys precisely that artefact. This satisfies the stem's consistency requirement, preventing drift from mutable tags such as latest across environments.

Why this answer

Image tagging in a GitOps workflow provides a unique, immutable identifier for a specific version of a container image. By using a tag (e.g., a Git commit SHA or semantic version), you ensure that the exact same image is deployed consistently across environments and over time. This supports reproducibility and rollback.

Exam trap

CGOA often tests the misconception that image tags are for operational actions like restarting containers or tracking users, when their primary purpose is versioning and ensuring consistent deployment of the correct application version.

How to eliminate wrong answers

Option A is wrong because forcing a container to restart is typically done by changing a pod template annotation or using kubectl rollout restart, not by image tagging. Option C is wrong because tracking user logins is an application-level concern, unrelated to image tags. Option D is wrong because image tagging does not govern registry cleanup; retention policies or lifecycle rules handle deletion of old images.

Full explanation →

143

Multi-Selecthard

Which THREE of the following are common components of a GitOps platform?

Select 3 answers

A.CI Pipeline (e.g., GitHub Actions)

B.External Load Balancer

C.Git Repository (Source of Truth)

D.Manual Deployment Script

E.GitOps Operator (e.g., Argo CD/Flux)

AnswersA, C, E

A CI pipeline builds and tests artefacts, then commits updated manifests or image tags back to Git. It supplies the automated build and validation stage that feeds the Git source of truth, though it holds no direct cluster access in a pull-based model.

Why this answer

A GitOps platform typically includes a CI pipeline such as GitHub Actions (option A), which builds, tests, and produces the immutable artifacts (container images, manifests) that the GitOps workflow then deploys. The Git repository (option C) is the declarative source of truth: it stores the desired state of the cluster, and every change is made via commits and pull requests rather than direct kubectl commands. The GitOps operator (option E), such as Argo CD or Flux, runs inside the cluster, continuously reconciles the live state against the repository, and reports or auto-corrects drift.

An external load balancer (option B) is an infrastructure/routing component, not a defining part of a GitOps platform, and a manual deployment script (option D) contradicts GitOps' declarative, automated, pull-based reconciliation model.

Exam trap

CGOA often tests the misconception that any deployment automation tool (like a CI pipeline or manual script) is part of GitOps, when in fact GitOps requires a Git repository as the source of truth and an operator for continuous reconciliation.

Full explanation →

144

Multi-Selectmedium

Which TWO of the following are characteristics of a 'GitOps Operator'?

Select 2 answers

A.It is a purely external monitoring tool

B.It generates application source code

C.It runs inside the Kubernetes cluster

D.It requires manual triggers for every update

E.It observes, compares, and acts to reconcile state

AnswersC, E

Running inside the Kubernetes cluster lets the operator watch custom resources and reconcile cluster state continuously, satisfying the stem's requirement for an in-cluster control loop. This contrasts with external CI pipelines, which push changes from outside and cannot self-heal drift without cluster-resident reconciliation.

Why this answer

Option C is correct because a GitOps Operator is deployed as a controller inside the Kubernetes cluster, where it watches custom resources and continuously manages the desired state of the environment. Option E is correct because the core function of a GitOps Operator is to observe the live cluster state, compare it against the desired state declared in Git, and act to reconcile any drift automatically. Options A, B, and D are incorrect: a GitOps Operator is not merely an external monitoring tool, it does not generate application source code, and it does not require manual triggers for every update since reconciliation is continuous and automated.

Exam trap

CGOA often tests whether candidates confuse the GitOps operator with external CI/monitoring tools — the trap is selecting 'external monitoring tool' or 'manual triggers' when the operator is in-cluster and automatic.

Full explanation →

145

MCQeasy

Which of these is a typical 'Desired State' artifact in GitOps?

A.An audit log from the cluster.

B.A shell script that installs software.

C.A live running container.

D.A Kubernetes YAML manifest.

AnswerD

A Kubernetes YAML manifest declares resources such as Deployments and Services in a machine-readable, version-controllable form. Committing it to Git gives the reconciler an unambiguous desired state to converge towards, unlike imperative scripts or console changes.

Why this answer

In GitOps, the desired state is the declarative configuration that defines how the system should look. A Kubernetes YAML manifest is a canonical example: it declares resources like Deployments, Services, and ConfigMaps. This manifest is stored in Git and used by GitOps operators to reconcile the live cluster.

Exam trap

CGOA often tests the confusion between desired state (declarative configuration) and actual state (live resources) or imperative scripts, leading candidates to choose operational artifacts instead of declarative manifests.

How to eliminate wrong answers

Option A is wrong because an audit log is a record of past events, not a desired state artifact; it is observational, not declarative. Option B is wrong because a shell script is imperative and describes steps to execute, not a declarative desired state. Option C is wrong because a live running container is the actual state, not the desired state; it is what the operator reconciles towards.

Full explanation →

146

MCQhard

What is the primary risk of a 'Push-based' deployment model compared to 'Pull-based'?

A.The Git repository is too big.

B.It requires the CI system to have broad permissions on the cluster.

C.It's too slow.

D.It makes it impossible to use Git.

AnswerB

Push-based pipelines run outside the cluster and therefore need credentials with broad write permissions to apply manifests, unlike pull-based controllers that hold credentials internally. This expanded attack surface is the primary risk relative to pull-based deployment.

Why this answer

In push-based deployment, the CI system must hold credentials with write access to the cluster (kubeconfig or service account token) to apply manifests. That credential is stored in the CI platform and, if compromised, grants an attacker broad cluster permissions. Pull-based models avoid this by having an in-cluster agent fetch from Git with only read access.

Exam trap

CGOA often tests the misconception that push-based is risky because of speed or repo size — the real risk is the broad, long-lived cluster credentials the CI system must hold, which pull-based models eliminate.

How to eliminate wrong answers

Option A is wrong because repository size is unrelated to the push/pull distinction; both models can use large or small repos, and Git handles large repos with shallow clones and sparse checkouts. Option C is wrong because speed is not the defining risk — push can be faster (immediate) while pull may poll, but the security trade-off is the primary concern, not latency. Option D is wrong because push-based CI/CD absolutely can and does use Git; the model describes how changes reach the cluster, not whether Git is involved.

Full explanation →

147

MCQeasy

Your team is integrating a CI pipeline with a GitOps delivery model. Which of the following tasks should remain in the CI pipeline, and which should be moved to the CD/GitOps reconciliation process?

A.Everything, including image building and deployment, must be handled by the GitOps controller.

B.The CI pipeline should perform the final deployment to ensure the pipeline status is correctly reported.

C.Container image building and unit testing remain in CI, while manifest deployment to the cluster moves to GitOps.

D.Container image building moves to GitOps, while manifest deployment remains in the CI pipeline.

AnswerC

Building images and running unit tests are CI concerns producing immutable artefacts, whereas deploying manifests is a CD concern. Moving deployment to the GitOps reconciler keeps the cluster state continuously synced to Git, matching the stem's split of responsibilities.

Why this answer

In a GitOps model, the CI pipeline is responsible for building and testing artifacts (e.g., container images, unit tests), while the CD/GitOps reconciliation process handles deploying those artifacts to the cluster by syncing the desired state from Git. Option C correctly separates these concerns: CI produces immutable artifacts and updates manifests, and GitOps controllers (like Argo CD or Flux) continuously reconcile the cluster to match the Git repository. This division ensures that deployment is declarative, auditable, and automated without direct CI access to the cluster.

Exam trap

CGOA often tests the misconception that GitOps replaces CI entirely or that CI should retain deployment control, confusing the distinct responsibilities of building artifacts versus reconciling cluster state.

How to eliminate wrong answers

Option A is wrong because GitOps controllers do not build container images; they only deploy pre-built artifacts from a registry, and delegating image building to them would break the separation of concerns and require cluster-level build capabilities. Option B is wrong because having the CI pipeline perform the final deployment contradicts the GitOps principle of continuous reconciliation from Git, and it would give CI direct cluster credentials, undermining security and auditability. Option D is wrong because it reverses the roles: GitOps does not build images (that requires a build environment, not a reconciliation loop), and keeping manifest deployment in CI defeats the purpose of GitOps, which is to have the cluster state managed declaratively via Git.

Full explanation →

148

MCQmedium

What happens if the Git repository is temporarily unavailable during a sync cycle?

A.The operator wipes the current state

B.The cluster reverts to a hardcoded default

C.The cluster automatically deletes all applications

D.The operator waits and retries the fetch

AnswerD

When the Git repository is unreachable, the operator's reconciliation loop simply requeues and retries the fetch rather than failing permanently, so no configuration is lost. This satisfies the stem's temporary-unavailability constraint: sync resumes automatically once connectivity returns, preserving the desired state declared in Git.

Why this answer

GitOps operators such as Argo CD or Flux are designed to be resilient to transient failures. When the Git repository is temporarily unreachable, the operator does not alter the cluster; it simply waits and retries the fetch on its next reconciliation loop, preserving the last known desired state. This ensures the cluster remains stable and avoids destructive actions caused by a temporary network or repository outage.

Exam trap

CGOA often tests the misconception that a Git outage causes the operator to take drastic action; the correct understanding is that the operator is non-destructive and simply retries, preserving the last known good state.

How to eliminate wrong answers

Option A is wrong because wiping the current state would be destructive and is never the behaviour of a GitOps operator during a transient Git outage; operators preserve the last applied state. Option B is wrong because GitOps operators do not fall back to hardcoded defaults — the desired state is defined in Git, and if Git is unreachable, the operator simply cannot reconcile but does not invent a default. Option C is wrong because deleting all applications would be catastrophic and is not a behaviour of any mature GitOps operator; the operator has no reason to delete resources just because Git is temporarily unavailable.

Full explanation →

149

MCQmedium

In a GitOps promotion pipeline, why is it recommended to tag container images with a unique Git commit SHA instead of 'latest'?

A.Because the container registry requires unique SHAs.

B.To reduce the size of the container image.

C.Because 'latest' is deprecated by Docker.

D.To ensure immutability and auditability.

AnswerD

SHA-based tagging is essential for reliable GitOps.

Why this answer

Tagging container images with a unique Git commit SHA ensures immutability because the tag directly corresponds to a specific commit, making it easy to trace back to the exact source code. This provides auditability, as you can always identify which code version is running. Using 'latest' is mutable and can lead to inconsistent deployments.

Exam trap

CGOA often tests the importance of immutability in GitOps, and candidates may incorrectly think that 'latest' is deprecated or that registries require unique tags, missing the core reason of auditability and immutability.

How to eliminate wrong answers

Option A is wrong because container registries do not require unique SHAs; they allow any tag, including 'latest', though best practices recommend unique tags. Option B is wrong because the tag does not affect the size of the container image; image size is determined by layers and content. Option C is wrong because 'latest' is not deprecated by Docker; it is still a valid tag, but it is discouraged for production due to mutability.

Full explanation →

150

MCQmedium

Your organization uses a 'GitOps Operator' to manage deployments. What happens if a developer manually changes a configuration on the Kubernetes cluster using 'kubectl edit'?

A.The GitOps operator will enter a 'halt' state and require manual intervention to synchronize.

B.The GitOps operator will detect the drift and revert the manual change to match the configuration in Git.

C.The GitOps operator will trigger an alert, but the manual change will remain in place until the next deployment.

D.The GitOps operator will automatically update the Git repository to reflect the manual change.

AnswerB

GitOps operators continuously reconcile cluster state against the Git repository, which is the declared source of truth. A manual kubectl edit creates drift, so the operator reapplies the Git manifest and overwrites the change, restoring the desired state.

Why this answer

A GitOps operator continuously compares the desired state in Git with the live cluster state and reconciles any drift. When a developer uses 'kubectl edit' to change a resource, the operator detects the divergence on its next sync loop and reverts the resource to match Git, restoring the declared state. This self-healing behaviour is a core GitOps guarantee.

Exam trap

CGOA often tests the misconception that GitOps operators alert on drift but leave manual changes in place, or that they sync cluster changes back to Git — both misunderstand the one-way, Git-to-cluster reconciliation model.

How to eliminate wrong answers

Option A is wrong because GitOps operators do not halt on drift — they actively reconcile; halting would defeat the purpose of continuous reconciliation. Option C is wrong because the operator does not merely alert and leave the change in place; it reverts the drift automatically (alerts may also fire, but reversion is the defining behaviour). Option D is wrong because the operator never writes back to Git from cluster state — Git is the source of truth, and reverse-syncing would allow unaudited changes to become canonical, violating GitOps principles.

Full explanation →

Certified GitOps Associate (CGOA, CNCF/Linux Foundation) (CGOA) (CGOA) — Questions 76–150