CCNA Gitops Principles Questions — Page 1 of 2

Multi-Selecthard

Which THREE of the following are core requirements for adopting a GitOps-based workflow?

Select 3 answers

A.Declarative infrastructure definitions in Git.

B.Proprietary hardware load balancers.

C.A cluster-side agent for reconciliation.

D.A full-time manual administrator.

E.A versioned history of state changes.

AnswersA, C, E

GitOps requires the desired state to be expressed declaratively so tooling can compare it against live cluster state and reconcile automatically. Storing these definitions in Git provides the versioned, reviewable source of truth that the pull-based workflow depends on.

Why this answer

Option A is correct because GitOps requires the desired state of infrastructure and applications to be expressed declaratively (e.g., Kubernetes YAML manifests) and stored in Git as the single source of truth. Option C is correct because a cluster-side agent, such as Argo CD or Flux, continuously reconciles the live cluster state against the declared state in Git. Option E is correct because Git's versioned history provides an auditable, immutable record of every state change, enabling rollbacks and traceability.

Option B is incorrect because GitOps is tool-agnostic and does not require proprietary hardware load balancers. Option D is incorrect because GitOps emphasizes automation and continuous reconciliation, reducing the need for manual administrative intervention.

Exam trap

CGOA often tests the core principles of GitOps versus traditional CI/CD — candidates may confuse optional tooling or legacy practices with mandatory GitOps requirements.

Practice this question →

Multi-Selectmedium

Which TWO of the following are core principles of GitOps?

Select 2 answers

A.Declarative desired state.

B.Using a GUI for all configuration tasks.

C.Use of imperative CLI commands.

D.Continuous drift detection and correction.

E.Manual approval for every single sync.

AnswersA, D

GitOps stores the entire desired system state declaratively in Git, so the repository describes what the system should be rather than the steps to reach it. Controllers continuously reconcile live state to that declaration, making declarative desired state a core principle.

Why this answer

Option A (Declarative desired state) is correct because GitOps stores the entire system's desired configuration as declarative manifests (e.g., Kubernetes YAML, Helm charts) in a Git repository, which serves as the single source of truth rather than a series of imperative steps. Option D (Continuous drift detection and correction) is correct because a GitOps controller (such as Argo CD or Flux) continuously reconciles the live cluster state against the declared state in Git, automatically detecting and correcting any drift to keep them in sync. Option B is incorrect because GitOps is not about using a GUI for configuration; changes are made through Git commits and pull requests, and GUIs are optional at best.

Option C is incorrect because GitOps relies on declarative configuration rather than imperative CLI commands, which describe step-by-step actions instead of a desired end state. Option E is incorrect because GitOps emphasizes automated continuous reconciliation, not manual approval for every sync, though approvals may occur at the pull-request stage before merging.

Exam trap

CGOA often tests the distinction between declarative (GitOps) and imperative (traditional) operations — candidates pick imperative CLI usage thinking it is compatible, but it violates the core GitOps principle.

Practice this question →

MCQeasy

Which of the following is considered an 'Anti-pattern' in a GitOps workflow?

A.Storing infrastructure definitions as code

B.Automated testing of configuration before merging to main

C.Using pull requests to review configuration changes

D.Applying 'hotfixes' directly to the cluster via kubectl

AnswerD

Editing the cluster directly with kubectl bypasses Git, so the source of truth no longer reflects reality and the reconciler will revert the change or drift silently. This breaks the declarative, auditable workflow GitOps depends on, making it a classic anti-pattern.

Why this answer

Applying 'hotfixes' directly to the cluster via kubectl is an anti-pattern in GitOps because it bypasses the declarative, version-controlled workflow. GitOps requires all changes to be made through Git, ensuring auditability, reproducibility, and consistency. Direct kubectl changes cause drift and are not tracked in Git.

Exam trap

CGOA often tests the identification of anti-patterns, and candidates may mistakenly think that any automated or scripted change is acceptable, missing that direct cluster modifications violate GitOps principles.

How to eliminate wrong answers

Option A is wrong because storing infrastructure definitions as code is a core GitOps practice, not an anti-pattern. Option B is wrong because automated testing of configuration before merging is a best practice that improves reliability. Option C is wrong because using pull requests to review configuration changes is a recommended GitOps practice for collaboration and quality control.

Practice this question →

MCQmedium

When configuring a GitOps tool, what is the purpose of a 'webhook' in relation to the Git repository?

A.To encrypt the traffic between the cluster and Git.

B.To trigger an immediate reconciliation attempt when a push occurs.

C.To replace the need for an SSH key.

D.To store the application images.

AnswerB

A webhook lets the Git repository notify the GitOps controller on push, prompting an immediate reconciliation instead of waiting for the next polling interval. This satisfies the requirement for low-latency deployment triggered by repository changes.

Why this answer

A webhook is an HTTP callback that the Git provider (GitHub, GitLab, Bitbucket) sends to the GitOps controller when events like a push occur. This lets the controller trigger an immediate reconciliation instead of waiting for its polling interval, cutting sync latency from minutes to seconds. It is an optimization, not a replacement for the controller's pull-based reconciliation.

Exam trap

CGOA often tests the misconception that webhooks replace authentication or encryption, when their sole purpose is triggering faster reconciliation on Git events.

How to eliminate wrong answers

Option A is wrong because webhooks are plain HTTP POST payloads and do not encrypt traffic; TLS is handled separately by HTTPS endpoints and Git's own transport. Option C is wrong because webhooks do not replace SSH keys or credentials; authentication to Git still requires SSH keys, tokens, or app passwords. Option D is wrong because webhooks carry event metadata, not container images; images live in a registry, not in the webhook payload.

Practice this question →

MCQeasy

Which of the following best describes the 'Declarative' principle in GitOps?

A.Using an interactive terminal to manage resources.

B.Providing a script to update resources.

C.Defining the target state in configuration files.

D.Requiring manual approval for every reconciliation.

AnswerC

Defining the target state in configuration files satisfies the declarative principle because Git stores the desired end state rather than imperative commands. The cluster's controllers continuously reconcile actual state against that committed specification, so the constraint of version-controlled, auditable desired state is met without scripting each step.

Why this answer

Declarative means you describe the desired end state in version-controlled configuration files (YAML/JSON/HCL), and a controller continuously reconciles reality to match it. You declare 'what' the system should look like, not 'how' to get there step by step. This is the foundation that makes Git the single source of truth in GitOps.

Exam trap

The trap here is conflating 'declarative' with 'scripted' or 'automated' — a script is automated but still imperative, and candidates often pick it because it sounds like infrastructure-as-code.

How to eliminate wrong answers

Option A is wrong because an interactive terminal is imperative and ad-hoc — it leaves no versioned record and cannot be reconciled automatically. Option B is wrong because a script is imperative: it encodes a sequence of commands ('how'), which may produce different results depending on starting state and is not idempotent by nature. Option D is wrong because declarative reconciliation is automatic and continuous; requiring manual approval for every reconciliation defeats the purpose and is not part of the declarative principle.

Practice this question →

Multi-Selectmedium

Which TWO are common strategies for GitOps repo structure?

Select 2 answers

A.Creating one repository per single microservice.

B.Directory-per-environment.

C.Never using branches.

D.Storing all files in a single flat directory.

E.App-of-Apps pattern.

AnswersB, E

Directory-per-environment places each environment's manifests in its own folder within one branch, letting overlays or values files customise shared bases. This preserves a single source of truth while isolating environment differences, satisfying the requirement for a clear, reviewable GitOps repository structure.

Why this answer

Option B (Directory-per-environment) is correct because a common GitOps strategy is to organize a repository with separate directories for each environment (e.g., dev, staging, prod), allowing environment-specific manifests and overlays to be managed independently while sharing a common base. Option E (App-of-Apps pattern) is correct because in Argo CD-based GitOps, the App-of-Apps pattern uses a parent Application that points to a directory of child Application manifests, enabling hierarchical, declarative management of many applications from a single repo structure. Option A is not a standard GitOps repo-structuring strategy; while one repo per microservice can occur, GitOps commonly favors monorepos or environment-based layouts, and this is not one of the two recognized patterns here.

Option C is incorrect because branches are routinely used in GitOps workflows (e.g., feature branches, environment branches), so 'never using branches' is not a valid strategy. Option D is incorrect because a single flat directory does not scale, provides no environment separation, and is not a recognized GitOps structuring strategy.

Exam trap

CGOA often tests the confusion between common scalable patterns (directory-per-environment, App-of-Apps) and impractical anti-patterns (one repo per microservice, flat directory), leading candidates to choose options that sound organized but do not scale.

Practice this question →

MCQmedium

When implementing a GitOps workflow with Argo CD, what is the role of the 'AppProject' custom resource?

A.It automatically triggers infrastructure rollbacks upon failure

B.It defines the build pipeline for container images

C.It stores the Git credentials for the entire cluster

D.It enforces security boundaries and scope for a set of applications

AnswerD

AppProject enforces security boundaries and scope for a set of applications, satisfying the requirement to restrict which repositories, clusters and namespaces a team may deploy to. It defines sourceRepos, destinations and clusterResourceWhitelist, so RBAC and tenancy limits are applied per project rather than globally.

Why this answer

The AppProject custom resource in Argo CD is a logical grouping of applications that defines security boundaries and scope. It restricts which Git repositories, Kubernetes clusters, and namespaces an application can deploy to, and can enforce RBAC and sync policies. This makes it the primary multi-tenancy and governance mechanism in Argo CD.

Exam trap

CGOA often tests the misconception that AppProject handles build pipelines or credentials, when its core purpose is to enforce security boundaries and scope for applications.

How to eliminate wrong answers

Option A is wrong because automatic rollbacks are handled by Argo CD's sync policies and health checks, not by AppProject; AppProject only defines boundaries. Option B is wrong because build pipelines for container images are the domain of CI tools like Jenkins, GitLab CI, or Tekton, not Argo CD's AppProject. Option C is wrong because Git credentials are stored in Argo CD's repository secrets (e.g., Kubernetes Secrets), not in AppProject; AppProject can restrict which repos are allowed but does not store credentials.

Practice this question →

MCQmedium

Why must the desired state be 'versioned' in Git in a GitOps architecture?

A.To allow the cluster to write data back to the Git repository.

B.To enable reliable rollbacks and environment reproducibility.

C.To automatically optimize cluster resource utilization.

D.To ensure developers can commit code directly to production.

AnswerB

Git history records every desired-state revision, so any prior commit can be redeployed to restore a known-good configuration. This satisfies the rollback and reproducibility requirement, since unversioned state offers no auditable path back to an earlier working cluster definition.

Why this answer

Versioning the desired state in Git provides an immutable, auditable history of every change, enabling reliable rollbacks to any prior commit and reproducible environments by checking out a specific tag or SHA. This is the foundation of GitOps's declarative, auditable model. Versioning is about traceability and reproducibility, not about cluster-to-Git writes or resource optimization.

Exam trap

CGOA often tests whether candidates understand GitOps as unidirectional (Git → cluster) — options implying the cluster writes back to Git or that versioning enables direct production commits are classic distractors.

How to eliminate wrong answers

Option A is wrong because GitOps is pull-based and one-directional; the cluster never writes data back to Git, as that would break the single source of truth and create race conditions. Option C is wrong because Git versioning has no bearing on cluster resource utilization — that's the job of the scheduler, HPA, VPA, and cluster autoscaler. Option D is wrong because versioning does not grant developers direct production commit rights; in fact, GitOps typically enforces PR review and CI validation before merges reach production, which is the opposite of bypassing controls.

Practice this question →

MCQmedium

When using Argo CD, what does the 'Sync Status' 'OutOfSync' indicate?

A.The cluster is disconnected from the network.

B.A new version of the application is available in the registry.

C.The live state differs from the desired state in Git.

D.The Git repository has been deleted.

AnswerC

OutOfSync means the resources currently running in the cluster do not match the manifests declared in the Git repository. Argo CD detects this drift during comparison and flags it, prompting a sync to reconcile live state with the desired Git state.

Why this answer

In Argo CD, 'OutOfSync' means the live Kubernetes cluster state does not match the desired state declared in the Git repository. Argo CD continuously compares the manifests in Git against the resources running in the cluster, and any difference (missing resource, changed field, extra resource) sets the Sync Status to OutOfSync. This is distinct from Health Status, which reflects whether resources are functioning correctly.

Exam trap

CGOA often tests the confusion between Sync Status (Git vs. live state) and Health Status (resource operational state), causing candidates to pick answers about connectivity or application health instead of configuration drift.

How to eliminate wrong answers

Option A is wrong because a disconnected cluster is reflected in the Connection Status (e.g., 'Unknown' or 'Failed'), not the Sync Status. Option B is wrong because a new image version in a registry is irrelevant unless the Git manifest is updated to reference it — Argo CD does not poll registries for new tags. Option D is wrong because a deleted Git repository would cause Argo CD to fail fetching manifests (a repository/connection error), not produce a normal OutOfSync comparison result.

Practice this question →

MCQeasy

A team is transitioning to GitOps. Which action best aligns with the principle of Declarative Desired State?

A.Running a pipeline to execute terraform apply on demand

B.Writing a bash script to update image tags on all clusters

C.Using kubectl edit to modify running pod replicas

D.Storing YAML manifests in Git representing the target environment state

AnswerD

Storing YAML manifests in Git encodes the target environment state as versioned, declarative configuration, which is exactly what GitOps reconciles against. This satisfies the stem's requirement for a declarative desired state, since the manifests describe the intended end state rather than imperative deployment steps, letting tooling detect and correct drift automatically.

Why this answer

Declarative desired state in GitOps means the target environment state is expressed as declarative manifests (for example, Kubernetes YAML) stored in Git as the single source of truth. A controller then reconciles the live environment to match that declared state, which is exactly what storing YAML manifests in Git represents.

Exam trap

The trap is equating 'using Git' or 'running Terraform' with GitOps; the exam tests that declarative desired state specifically means storing declarative manifests in Git as the source of truth, not merely executing automation.

How to eliminate wrong answers

Option A is wrong because running 'terraform apply' on demand is imperative execution, not a declarative desired-state artifact stored in Git. Option B is wrong because a bash script that mutates image tags is imperative and procedural, not declarative. Option C is wrong because 'kubectl edit' directly mutates a running resource, which is an imperative manual change that bypasses Git as the source of truth.

Practice this question →

MCQeasy

Which statement best defines 'immutable state' in the context of GitOps?

A.The cluster hardware cannot be modified.

B.The container images cannot be changed.

C.The configuration committed to Git represents a fixed, unchangeable historical point.

D.The application state cannot be deleted.

AnswerC

Git commits form an append-only history: each revision is content-addressed and cryptographically chained, so a given commit hash always resolves to the same tree. This satisfies the definition by treating committed configuration as a fixed historical point, enabling deterministic rollback and drift detection against that exact revision.

Why this answer

In GitOps, immutable state means that a commit in Git represents a fixed, unchangeable point in history — it cannot be altered after the fact. This immutability provides an auditable, versioned record of desired state, enabling rollbacks and reproducibility. Changes are made by adding new commits, not by modifying existing ones.

Exam trap

CGOA often tests the misconception that immutability refers to cluster hardware or container images, when it actually refers to the unchangeable historical record of configuration in Git.

How to eliminate wrong answers

Option A is wrong because immutability in GitOps refers to configuration history in Git, not physical cluster hardware, which is outside the GitOps model. Option B is wrong because container images can be updated by changing the image tag or digest in Git; immutability refers to the Git commit, not the image itself (though image digests are often used for immutability). Option D is wrong because applications and their resources can be deleted via Git changes; immutability means the historical record cannot be changed, not that resources cannot be removed.

Practice this question →

MCQhard

In a multi-cluster environment, how does the GitOps principle of 'Declarative Desired State' simplify cluster management?

A.By allowing each cluster to define its own unique state manually.

B.By requiring a human operator to verify each cluster's state daily.

C.By eliminating the need for Git altogether.

D.By enabling template-based configuration across identical environments.

AnswerD

Storing declarative manifests in Git lets teams use templating tools such as Helm or Kustomize to generate per-cluster configuration from shared bases, so identical environments stay consistent while differing only in overlays. This satisfies the constraint of managing many clusters without duplicating manifests by hand.

Why this answer

Declarative desired state means the entire cluster configuration is expressed as versioned manifests in Git, which can be templated (Helm, Kustomize) and applied consistently across many clusters. This enables identical environments — dev, staging, production, or multiple regions — to be provisioned from the same parameterized source, eliminating configuration drift and manual per-cluster setup. The result is repeatable, auditable, and scalable multi-cluster management.

Exam trap

The trap is equating 'declarative' with 'manual per-cluster configuration' — candidates must recognize that declarative desired state is about templated, versioned, repeatable definitions, not bespoke per-cluster setups.

How to eliminate wrong answers

Option A is wrong because allowing each cluster to define its own unique state manually is the opposite of declarative desired state — it reintroduces drift and defeats the purpose of GitOps. Option B is wrong because requiring a human to verify each cluster daily is a manual, error-prone process that declarative GitOps explicitly replaces with automated reconciliation. Option C is wrong because Git is the foundational source of truth in GitOps; eliminating Git would remove the versioning, review, and audit capabilities that make declarative management work.

Practice this question →

MCQhard

In a GitOps architecture, why is it critical that the entire state of the system is declarative?

A.To allow for faster manual scaling of pods

B.To enable the reconciliation loop to calculate the necessary deltas for convergence

C.To ensure that Docker images are automatically rebuilt

D.To replace the need for RBAC in the Kubernetes cluster

AnswerB

Declarative state gives the reconciliation loop a complete desired-state specification to diff against observed reality, so it can compute precise deltas and converge continuously. Without it, the controller cannot determine what actions close the gap, breaking GitOps' automated drift correction — the core requirement this scenario demands.

Why this answer

A declarative model lets the reconciliation loop compare the desired state (from Git) with the observed live state and compute the specific deltas needed to converge. Without full declarative specification, the controller could not deterministically derive what to create, update, or delete, making automated convergence impossible. Declarative state is the foundation that makes Git the single source of truth.

Exam trap

CGOA often tests the misconception that declarative state is about performance or security benefits, when the real reason is enabling deterministic delta computation by the reconciliation loop.

How to eliminate wrong answers

Option A is wrong because declarative state is not about faster manual scaling; scaling is a specific action, and GitOps emphasizes automated, Git-driven changes rather than manual speed. Option C is wrong because image rebuilding is a CI concern triggered by code changes, not a consequence of declarative configuration. Option D is wrong because RBAC is still required to control who and what can access the cluster and Git; declarative state does not replace authorization mechanisms.

Practice this question →

MCQeasy

A DevOps team is storing its Kubernetes manifests in a Git repository. To adhere strictly to the principle of versioned and immutable desired state in Git, how should the team manage changes to an existing deployment's container image tag?

A.Commit a change updating the image tag in the manifest file within the Git repository and merge it via a pull request.

B.Exec into the running pod using 'kubectl exec' and update the container image binary directly.

C.Run 'kubectl set image deployment/my-app my-app=image:v2' against the live cluster without updating Git.

D.Delete the deployment using 'kubectl delete' and manually re-apply a temporary local manifest file.

AnswerA

Editing the manifest and merging via pull request keeps the desired state declarative and versioned in Git, so the reconciliation controller applies the new tag. This satisfies the immutable-state principle by making Git the only path for changes.

Why this answer

In GitOps, Git is the single source of truth for desired state, so any change to a deployment—including the container image tag—must be made by committing to the manifest in Git and merging via a pull request. The GitOps controller then reconciles the cluster to match. Direct cluster mutations bypass the audit trail and are reverted by reconciliation.

Exam trap

CGOA often tests whether candidates choose a convenient kubectl command over the Git-commit workflow, forgetting that any direct cluster mutation violates the GitOps principle that Git must remain the immutable, versioned source of truth.

How to eliminate wrong answers

Option B is wrong because exec'ing into a running pod to modify a binary is an imperative runtime change that is ephemeral, untracked in Git, and lost on pod restart; it violates immutable desired state. Option C is wrong because 'kubectl set image' mutates the live cluster directly without updating Git, creating drift that the GitOps engine will revert and leaving no versioned record. Option D is wrong because deleting and re-applying a local manifest is an out-of-band imperative action that bypasses Git review, breaks the audit trail, and will be overwritten by reconciliation.

Practice this question →

Multi-Selectmedium

When considering the GitOps principle of 'Declarative Desired State', which TWO of the following statements accurately reflect why manifests should be stored in Git?

Select 2 answers

A.To reduce the latency of image pull times

B.To serve as the single source of truth for the entire cluster configuration

C.To automatically encrypt all data in the database

D.To enable peer review and collaboration via Pull Requests

E.To allow the Git server to perform the cluster reconciliation

AnswersB, D

Git provides versioned, auditable storage that every cluster and operator reconciles against, making it the authoritative record of intended configuration. This satisfies the constraint that a single source of truth is needed, eliminating configuration drift caused by undocumented manual changes.

Why this answer

Option B is correct because storing manifests in Git makes the repository the single source of truth for the entire cluster configuration, so the declarative desired state is versioned, auditable, and can be reconciled by a GitOps operator such as Argo CD or Flux. Option D is correct because Git-based manifests enable peer review and collaboration through Pull Requests, allowing changes to the desired state to be reviewed, approved, and merged before being applied. Option A is incorrect because image pull latency is determined by container registry and node networking, not by where manifests are stored.

Option C is incorrect because Git does not automatically encrypt database data; encryption is handled by database or storage-level mechanisms. Option E is incorrect because reconciliation is performed by a GitOps controller running in the cluster, not by the Git server itself.

Exam trap

The trap is attributing active cluster behavior (reconciliation, encryption, image pulls) to Git itself — Git is a passive, versioned store; the GitOps agent is what acts on it.

Practice this question →

MCQmedium

In an Argo CD deployment, a developer notices that manual changes made via kubectl are being reverted automatically. What feature is responsible for this behavior?

A.Git commit hook triggers

B.Auto-Sync with Self-Heal enabled

C.Kubernetes admission controllers

D.Manual refresh button

AnswerB

Self-heal continuously reconciles live cluster state against the desired state declared in Git, so any drift introduced by kubectl is detected and reverted automatically. Without self-heal, auto-sync alone only applies new Git commits, leaving manual edits in place until the next sync.

Why this answer

Argo CD's Auto-Sync with Self-Heal enabled continuously compares the live cluster state against the desired state in Git and automatically reverts any drift. When a developer makes a manual kubectl change, the Application Controller detects the difference during its reconciliation loop and re-applies the Git-defined manifest, effectively undoing the manual change. Self-Heal is the specific sub-feature of automated sync that enforces this drift correction.

Exam trap

The trap is confusing Auto-Sync (applies Git changes to cluster) with Self-Heal (reverts cluster drift back to Git) — candidates often pick 'Auto-Sync' alone, but the question specifically describes reverting manual kubectl changes, which requires Self-Heal.

How to eliminate wrong answers

Option A is wrong because Git commit hooks trigger CI pipelines or webhooks on repository events; they do not monitor or revert live cluster state. Option C is wrong because Kubernetes admission controllers validate or mutate resources at creation time but do not continuously reconcile drift against Git — they have no knowledge of Git desired state. Option D is wrong because the manual refresh button in the Argo CD UI only triggers a one-time comparison and sync; it does not automatically revert changes on an ongoing basis.

Practice this question →

MCQeasy

In GitOps, what is a 'Merge Request' (or Pull Request) used for?

A.To review, approve, and audit proposed changes to the desired state.

B.To bypass security checks.

C.To perform unit tests on the code.

D.To delete the cluster.

AnswerA

A Merge Request provides the review, approval, and audit trail that GitOps requires before any change reaches the desired state. Because Git stores the declarative configuration, every proposed modification is inspected and recorded as a commit, satisfying the stem's demand for controlled, traceable change management rather than direct cluster edits.

Why this answer

In GitOps, a Merge Request (or Pull Request) is the mechanism to propose changes to the desired state stored in Git. It enables peer review, automated validation (e.g., CI checks), and an audit trail of who approved what and when. This aligns with GitOps principles of declarative, versioned, and auditable infrastructure.

Exam trap

CGOA often tests the confusion between Merge Requests as a review/audit mechanism versus a tool for testing or bypassing controls, when their primary role is governance of desired state changes.

How to eliminate wrong answers

Option B is wrong because Merge Requests are designed to enforce security and quality checks, not bypass them; they are a gate for review and approval. Option C is wrong because unit tests are typically run by CI pipelines triggered on the MR, but the MR itself is not the tool for performing tests. Option D is wrong because deleting the cluster is an operational action, not the purpose of a Merge Request; MRs manage configuration changes, not cluster lifecycle directly.

Practice this question →

MCQeasy

Which of these is NOT a principle of GitOps?

A.Versioned and immutable state.

B.Imperative manual updates.

C.Declarative desired state.

D.Automated reconciliation.

AnswerB

GitOps declares desired state in Git and lets a controller reconcile the cluster towards it automatically. Imperative manual updates bypass that declarative reconciliation loop, so they contradict the GitOps model and are not one of its principles.

Why this answer

GitOps principles are declarative desired state, versioned and immutable state in Git, automated reconciliation, and continuous drift correction. Imperative manual updates contradict the declarative model because they bypass Git as the source of truth and are not reproducible or auditable. Therefore, imperative manual updates is NOT a GitOps principle.

Exam trap

CGOA often tests the misconception that any automated deployment is GitOps, when the defining test is whether changes flow declaratively through Git rather than through imperative commands.

How to eliminate wrong answers

Option A is wrong as an answer because versioned and immutable state is a core GitOps principle (Git history provides versioning and immutability). Option C is wrong as an answer because declarative desired state is the foundational GitOps principle. Option D is wrong as an answer because automated reconciliation is a defining GitOps principle that continuously aligns live state with Git.

Practice this question →

MCQhard

Why is 'pull-based' reconciliation considered more secure than 'push-based' CI/CD?

A.Because the cluster initiates the connection.

B.Because it eliminates the need for Git.

C.Because Git requires passwords for every pull.

D.Because it removes the need for container images.

AnswerA

In pull-based GitOps the operator inside the cluster opens the outbound connection to Git, so no external system needs inbound cluster credentials or exposed API access. This removes the attack surface that push-based pipelines require.

Why this answer

In a pull-based model, an in-cluster agent (Argo CD, Flux) initiates outbound connections to Git and the registry, so no external system needs inbound access or cluster-admin credentials. This inverts the trust boundary: the cluster reaches out rather than an external CI server reaching in. That architectural inversion is what makes pull-based reconciliation more secure.

Exam trap

CGOA often tests the misconception that pull-based means 'no Git' or 'no credentials' — the real distinction is the direction of the connection and where the privileged credential lives, not the elimination of Git or authentication.

How to eliminate wrong answers

Option B is wrong because pull-based GitOps absolutely still requires Git — the repository is the source of truth that the agent polls or watches. Option C is wrong because Git does not require passwords on every pull; agents typically authenticate via SSH keys, deploy keys, or short-lived tokens, and public repos need no auth at all. Option D is wrong because container images remain the deployment artifact in both push and pull models; pull-based changes who deploys them, not whether images are used.

Practice this question →

Multi-Selectmedium

Which THREE components are typically involved in a GitOps reconciliation loop?

Select 3 answers

A.A controller running inside the cluster.

B.The Kubernetes API server.

C.A manual human approval gate for every change.

D.An external CI server that manually applies changes.

E.The Git repository containing manifests.

AnswersA, B, E

The controller watches desired state from Git and observed state in the cluster, then applies or corrects drift. Running inside the cluster, it is the active reconciler that closes the loop between declared manifests and live resources.

Why this answer

In a GitOps reconciliation loop, the Git repository containing manifests (E) is the single source of truth, holding the desired state that the system continuously compares against. A controller running inside the cluster (A) — such as Argo CD's application controller or Flux's kustomize-controller — watches that repo and performs the actual reconciliation by detecting drift and re-syncing. The Kubernetes API server (B) is the target of that reconciliation: the controller reads live object state from it and issues create/update/patch calls to converge the cluster on the desired state.

Option C is wrong because GitOps is designed for automated, continuous reconciliation, not per-change human approval gates (approval may exist as a policy, but it is not a core loop component). Option D is wrong because GitOps explicitly rejects an external CI server manually applying changes (push-based deploys); the in-cluster controller pulls and applies, rather than CI pushing kubectl/helm commands.

Exam trap

CGOA often tests the pull-versus-push distinction, catching candidates who include an external CI server or manual approval gate as part of the reconciliation loop.

Practice this question →

MCQmedium

When syncing a Git repository to a cluster, what is the 'Sync Policy' in Argo CD?

A.It sets the password for the Git repository.

B.It configures the frequency of the container health checks.

C.It defines whether the application should be synced automatically or manually.

D.It determines which Git branch is used for the deployment.

AnswerC

Sync Policy governs reconciliation behaviour: automated sync applies Git changes to the cluster whenever drift is detected, while manual sync requires an operator to trigger it. It therefore defines whether the application syncs automatically or manually, as the stem asks.

Why this answer

The Sync Policy in Argo CD controls whether the application is synchronized automatically when Git changes are detected, or only when a user manually triggers a sync. It is configured via the `syncPolicy.automated` field in the Application manifest, and can include options like self-heal and prune. It does not manage credentials, health check frequency, or branch selection.

Exam trap

CGOA often tests the confusion between sync policy (automated vs manual) and other Application fields like targetRevision (branch) or repository credentials.

How to eliminate wrong answers

Option A is wrong because repository credentials are configured in the repository secret or via `argocd repo add`, not in the Sync Policy. Option B is wrong because container health check frequency is a Kubernetes probe setting (liveness/readiness), not an Argo CD sync setting. Option D is wrong because the Git branch is specified in the Application's `source.targetRevision` field, not in the Sync Policy.

Practice this question →

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.

Practice this question →

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.

Practice this question →

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.

Practice this question →

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.

Practice this question →

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.

Practice this question →

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.

Practice this question →

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.

Practice this question →

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.

Practice this question →

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.

Practice this question →

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.

Practice this question →

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.

Practice this question →

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.

Practice this question →

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.

Practice this question →

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.

Practice this question →

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.

Practice this question →

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.

Practice this question →

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.

Practice this question →

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.

Practice this question →

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.

Practice this question →

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.

Practice this question →

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.

Practice this question →

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.

Practice this question →

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.

Practice this question →

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.

Practice this question →

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.

Practice this question →

MCQeasy

What is the primary function of the 'reconciliation loop' in GitOps?

A.To continuously compare actual state with Git and correct discrepancies.

B.To manage user access control for the cluster.

C.To compile source code into container images.

D.To update the documentation in the Git repository.

AnswerA

The reconciliation loop polls or watches Git for the declared desired state, compares it against live cluster resources, and applies or reverts changes so the two converge. This continuous comparison-and-correction mechanism is precisely what maintains Git as the authoritative source of truth.

Why this answer

The reconciliation loop is the core control mechanism of GitOps: an agent continuously observes the actual state of the cluster and compares it to the desired state stored in Git, then takes corrective action to eliminate any difference. This closed-loop feedback ensures the cluster converges on the declared configuration and stays there despite manual changes, failures, or drift. It is what makes Git the authoritative source of truth in practice.

Exam trap

The trap is confusing the reconciliation loop with CI/CD build pipelines — candidates must remember that GitOps reconciliation is about continuously enforcing desired state, not compiling code or managing access.

How to eliminate wrong answers

Option B is wrong because user access control is handled by RBAC and authentication mechanisms (OIDC, certificates), not by the reconciliation loop, which deals with configuration state rather than identity. Option C is wrong because compiling source code into container images is the job of a CI system (Jenkins, GitHub Actions, Tekton), which is separate from the GitOps reconciliation loop that deploys already-built artifacts. Option D is wrong because updating documentation in Git is a human or CI task; the reconciler reads from Git and writes to the cluster, not the other way around.

Practice this question →

MCQhard

If a GitOps controller detects that an image tag has been changed in the cluster but not in Git, what does the controller do?

A.Leaves the cluster in the new state.

B.Updates the Git repository with the new image tag.

C.Reverts the cluster state to match the Git repository.

D.Prompts the user for approval.

AnswerC

Reverting to the Git-declared state is exactly what reconciliation enforces: the controller continuously compares live cluster resources against the desired manifests in Git and, on detecting drift such as a manually altered image tag, overwrites the cluster value to restore the declared configuration. This satisfies the stem's requirement that Git remains the single source of truth.

Why this answer

In GitOps, the Git repository is the single source of truth. If the GitOps controller detects that the live cluster state differs from the desired state in Git (e.g., an image tag changed in the cluster but not in Git), it will revert the cluster to match Git. This enforces the declarative model and prevents configuration drift.

Exam trap

CGOA often tests the direction of reconciliation in GitOps, trapping candidates who think the controller updates Git from the cluster rather than the other way around.

How to eliminate wrong answers

Option A is wrong because leaving the cluster in the new state would violate the GitOps principle of Git as the source of truth and allow drift. Option B is wrong because the controller does not write back to Git; it only reconciles the cluster to match Git. Updating Git is a human or CI action.

Option D is wrong because GitOps controllers operate automatically without prompting for approval; they may alert, but the default behavior is to reconcile.

Practice this question →

MCQmedium

How does GitOps help with disaster recovery?

A.It prevents the disaster from happening in the first place.

B.It automatically buys new hardware.

C.It keeps a copy of your data in the Git repo.

D.You can restore the entire cluster state by pointing a new cluster to the Git repository.

AnswerD

Git stores the full desired cluster state declaratively, so a replacement cluster can be reconciled to that same state by a GitOps controller. This makes recovery deterministic and fast, satisfying disaster recovery without manual rebuilds.

Why this answer

GitOps aids disaster recovery by allowing you to restore the entire cluster state by pointing a new cluster to the Git repository. Since Git holds the declarative desired state, a new cluster can be provisioned and synced to match that state, enabling rapid recovery.

Exam trap

CGOA often tests the misconception that GitOps backs up data, but it only backs up configuration; candidates may choose the option about data copies.

How to eliminate wrong answers

Option A is wrong because GitOps does not prevent disasters; it helps recover from them. Option B is wrong because GitOps does not involve hardware procurement. Option C is wrong because Git stores configuration and manifests, not application data; data backup is separate.

Practice this question →

Multi-Selecthard

Which THREE of the following are essential components of an effective GitOps 'Continuous Drift Detection and Correction' strategy?

Select 3 answers

A.Continuous comparison loop between cluster live state and Git desired state

B.Alerting or automated synchronization when drift is detected

C.Strict access control to prevent manual changes to the cluster

D.Regular manual audits of the cluster state

E.Using a CI-based push pipeline to update the cluster

AnswersA, B, C

The continuous comparison loop repeatedly evaluates live cluster resources against the desired state declared in Git, which is the detection half of the strategy. Without this ongoing evaluation, drift would remain invisible until a manual audit occurred.

Why this answer

Option A is correct because drift detection fundamentally requires a continuous reconciliation loop that compares the cluster's live state against the desired state declared in Git, which is the core mechanism tools like Argo CD and Flux use. Option B is correct because detecting drift is only useful if it triggers an action — either an alert to operators or automated synchronization (self-heal) to bring the cluster back in line with Git. Option C is correct because strict RBAC and admission controls that prevent manual, out-of-band changes to the cluster reduce drift at its source and preserve Git as the single source of truth.

Option D is not correct because periodic manual audits are reactive and point-in-time, not continuous, so they cannot satisfy a continuous drift detection strategy. Option E is not correct because a CI-based push pipeline applies changes only when the pipeline runs, rather than continuously reconciling live state against Git as a pull-based GitOps agent does.

Exam trap

CGOA often tests the distinction between GitOps pull-based reconciliation and CI push-based deployment, trapping candidates who think a CI pipeline pushing changes is part of GitOps drift correction.

Practice this question →

MCQeasy

Which of these is a valid 'GitOps' approach for multi-environment management?

A.Using separate directories or branches for different environments (e.g., /overlays/prod).

B.Ignoring environments and deploying everything to one namespace.

C.Using a single folder for all environments and using a script to toggle them.

D.Deploying directly to production using kubectl.

AnswerA

Kustomize overlays or per-environment branches let one repository hold distinct manifests, so each environment's desired state stays declarative and versioned. This satisfies the multi-environment constraint by isolating prod from staging without duplicating the base configuration.

Why this answer

The correct answer is A because GitOps relies on declarative infrastructure stored in Git, and using separate directories or branches for each environment (e.g., /overlays/prod) is a standard pattern to manage multi-environment configurations. This approach allows environment-specific customizations (like replicas, resource limits, or image tags) while keeping the base configuration DRY, often implemented with tools like Kustomize or Helm. It also enables independent promotion and rollback per environment via Git commits.

Exam trap

CGOA often tests the misconception that any automated deployment from Git qualifies as GitOps, when in fact GitOps requires a declarative, pull-based reconciliation loop with Git as the single source of truth, not imperative scripts or direct kubectl commands.

How to eliminate wrong answers

Option B is wrong because ignoring environments and deploying everything to one namespace violates isolation and least-privilege principles, making it impossible to manage environment-specific configurations or promote changes safely. Option C is wrong because using a single folder with a toggle script is imperative and not declarative; GitOps requires the desired state to be fully described in Git, not manipulated by scripts at deploy time. Option D is wrong because deploying directly to production using kubectl bypasses Git as the source of truth, breaking the GitOps principle of continuous reconciliation from a version-controlled repository.

Practice this question →

Multi-Selectmedium

A company is adopting GitOps and wants to ensure their implementation follows the core principles. They are reviewing their current practices and need to identify which of the following are considered core GitOps principles. (Choose two.)

Select 2 answers

A.Automated reconciliation

B.Declarative configuration

C.Push-based deployment

D.Manual approval for every change

E.Immutable infrastructure

AnswersA, B

Automated reconciliation is a core GitOps principle where an agent continuously compares the live state with the desired state in Git and corrects any drift. This ensures the system remains in the desired state without manual intervention. It is fundamental to GitOps and distinguishes it from traditional CI/CD that may only apply changes once.

Why this answer

The core GitOps principles include declarative configuration, Git as the single source of truth, automated reconciliation, and pull-based deployment. Among the options, declarative configuration and automated reconciliation are explicitly core principles. Manual approval for every change and push-based deployment contradict GitOps automation and pull-based models, while immutable infrastructure is a related but not core principle.

Exam trap

The trap here is selecting immutable infrastructure as a core principle because it is often associated with GitOps, but it is not one of the four key principles.

Practice this question →

MCQmedium

A DevOps team is adopting GitOps for their Kubernetes environment. They want to ensure that all changes to the cluster are made through Git, and that the cluster state is always in sync with the Git repository. They also want to avoid manual kubectl commands. Which GitOps principle is most directly violated if a team member uses 'kubectl apply' to update a Deployment?

A.Automated delivery

B.Immutable infrastructure

C.Declarative configuration

D.Git as the single source of truth

AnswerD

Git as the single source of truth means all desired state is stored in Git and changes are made via Git. Using 'kubectl apply' directly modifies the cluster without updating Git, so the cluster state diverges from Git. This violates the principle because Git no longer reflects the actual desired state, and reconciliation may revert the change.

Why this answer

Git as the single source of truth requires that all desired state be stored in Git and changes be made via Git. Using 'kubectl apply' directly modifies the cluster without updating Git, causing drift and violating this principle. The reconciliation loop would eventually revert the change, but the manual action itself breaks the GitOps workflow.

Exam trap

The trap here is thinking that any declarative change is acceptable, even if it bypasses Git, but GitOps requires Git to be the sole source of truth.

Practice this question →

MCQmedium

An organization uses Argo CD to manage Kubernetes clusters. A developer manually modifies a Deployment's replica count via kubectl. Which mechanism in Argo CD ensures this manual change is identified as non-compliant with the GitOps repository?

A.Git repository webhook

B.Kubernetes admission controllers

C.Kubernetes Garbage Collector

D.Argo CD Application Controller's reconciliation loop

AnswerD

The Application Controller continuously compares the live cluster state against the desired manifest held in Git. When the replica count is edited via kubectl, the next reconciliation cycle detects the difference and reports the Application as OutOfSync, flagging the change as non-compliant.

Why this answer

Argo CD's Application Controller runs a continuous reconciliation loop that periodically compares the desired state in Git with the live state in the cluster. When a developer manually changes a Deployment's replica count via kubectl, the controller detects the difference (OutOfSync) and, if auto-sync with self-heal is enabled, reverts the live resource to match Git. This is the core drift-detection mechanism in Argo CD.

Exam trap

CGOA often tests whether candidates confuse Git-side triggers (webhooks) or Kubernetes-native controllers (admission, GC) with Argo CD's own reconciliation loop, which is the only component that actually compares Git to live state.

How to eliminate wrong answers

Option A is wrong because a Git repository webhook only notifies Argo CD of new commits; it does not detect live-cluster drift caused by kubectl changes. Option B is wrong because Kubernetes admission controllers validate or mutate API requests at creation/update time; they do not compare against Git and are not part of Argo CD's drift detection. Option C is wrong because the Kubernetes Garbage Collector deletes orphaned objects based on ownerReferences, not Git-vs-live manifest differences.

Practice this question →

MCQhard

A company uses Flux to manage a Kubernetes cluster. During a recent security audit, they found that an engineer manually edited a ConfigMap directly in the live cluster using 'kubectl edit', causing the cluster state to drift from the Git repository. The engineer wants to ensure that such manual changes are automatically reverted to match Git. Which GitOps principle should they enforce?

A.Declarative configuration

B.Pull-based reconciliation

C.Immutable infrastructure

D.Continuous reconciliation

AnswerD

Continuous reconciliation is the GitOps principle that the agent constantly compares the live state with the desired state in Git and corrects any drift. In this scenario, enabling continuous reconciliation in Flux ensures that manual edits like the ConfigMap change are detected and reverted, restoring the cluster to the state defined in Git.

Why this answer

Continuous reconciliation ensures the cluster state is continuously compared to the desired state in Git and any drift is corrected. Manual edits like the ConfigMap change are automatically reverted, enforcing the Git repository as the single source of truth. This principle is fundamental to GitOps and is implemented by tools like Flux and Argo CD.

Exam trap

The trap here is confusing continuous reconciliation with pull-based reconciliation, thinking that pulling from Git alone will revert manual changes.

Practice this question →

MCQmedium

You are using Argo CD. A developer manually scales a Deployment replica count using 'kubectl scale'. What happens next in a standard GitOps implementation?

A.Argo CD sends an alert but does not revert the change.

B.The controller updates Git to reflect the new replica count.

C.The controller detects the drift and overwrites the manual change to match Git.

D.The change persists until the next Git commit.

AnswerC

Argo CD continuously reconciles live cluster state against the desired state declared in Git. When a manual `kubectl scale` diverges from Git, the controller's sync loop detects the drift and reverts the replica count, restoring Git as the single source of truth.

Why this answer

Argo CD continuously monitors the live cluster state against the desired state defined in Git. When a manual change like `kubectl scale` alters the replica count, Argo CD detects this as a drift from the Git-declared configuration. By default, Argo CD's reconciliation loop will automatically sync the application, overwriting the manual change to restore the replica count specified in Git.

This enforces the GitOps principle that Git is the single source of truth.

Exam trap

CGOA often tests the misconception that Argo CD will update Git to match manual changes, but GitOps strictly enforces Git as the source of truth, so manual changes are reverted.

How to eliminate wrong answers

Option A is wrong because Argo CD does not merely alert on drift; it actively reverts it unless configured otherwise (e.g., with sync policies disabled). Option B is wrong because Argo CD never writes back to Git; it only reads from Git and applies changes to the cluster. Option D is wrong because the change does not persist until the next Git commit; Argo CD's reconciliation loop detects and corrects drift immediately (within the sync interval), not waiting for a Git commit.

Practice this question →

MCQmedium

A developer pushes a change to Git, but the cluster does not update. Which log source is most effective for debugging the pull-based mechanism?

A.The browser console of the user.

B.The logs of the GitOps controller (e.g., Argo CD repo-server or Flux controller).

C.The application's logs inside the pod.

D.The Git provider's audit logs.

AnswerB

The GitOps controller performs the pull-based reconciliation, fetching commits and applying manifests. Its logs record source fetch failures, authentication errors, and apply conflicts, making them the most direct evidence when a pushed change never reaches the cluster.

Why this answer

The GitOps controller (Argo CD repo-server or Flux controller) is responsible for the pull-based reconciliation loop: it periodically fetches the desired state from Git, compares it to the live cluster state, and applies any differences. When a Git push does not result in a cluster update, the failure lies within this reconciliation process—such as an inability to fetch the repository, a manifest rendering error, or a sync policy misconfiguration. Therefore, the controller's logs are the most direct and effective source for diagnosing why the change was not applied.

Exam trap

CGOA often tests the misconception that application-level logs or Git provider audit logs are sufficient for debugging GitOps sync issues, when in fact the pull-based mechanism's failures are almost always revealed in the GitOps controller's logs.

How to eliminate wrong answers

Option A is wrong because the browser console of the user only shows client-side JavaScript errors and network requests from the web UI; it does not reveal server-side reconciliation failures or Git fetch issues. Option C is wrong because the application's logs inside the pod reflect the runtime behavior of the deployed application, not the GitOps controller's attempts to synchronize with Git; if the pod is running an old version, its logs will not indicate why the new commit was not applied. Option D is wrong because the Git provider's audit logs only record Git operations (e.g., pushes, pulls, permission changes) on the repository side; they can confirm that a push occurred but cannot explain why the GitOps controller failed to detect or apply that change to the cluster.

Practice this question →

MCQeasy

What is the primary role of an 'Immutable' state in a GitOps repository?

A.To increase the storage capacity of the cluster.

B.To allow the cluster to delete resources at will.

C.To force developers to use a specific IDE.

D.To ensure that historical configurations can be reliably rolled back.

AnswerD

Immutability means each commit is a permanent, versioned snapshot that is never edited in place, so any prior commit hash can be checked out and redeployed verbatim. This directly satisfies the rollback requirement, since the exact historical configuration remains retrievable rather than being overwritten by later changes.

Why this answer

In GitOps, an immutable repository state means that once a configuration is committed, it is never modified in place — changes are made by creating new commits. This immutability provides a reliable audit trail and ensures that any historical configuration can be deterministically rolled back by checking out a previous commit. It is a core principle that enables reproducibility and disaster recovery in GitOps workflows.

Exam trap

The trap is interpreting 'immutable' as a runtime cluster property (like immutable infrastructure) rather than a version control property — the exam tests whether you understand that immutability in GitOps refers to the Git history enabling reliable rollbacks.

How to eliminate wrong answers

Option A is wrong because immutability has nothing to do with cluster storage capacity — it is a version control and configuration management principle. Option B is wrong because immutability actually restricts arbitrary deletion; it ensures that historical states are preserved, not that the cluster can delete resources at will. Option C is wrong because immutability does not mandate any specific IDE — developers can use any tool, but they must commit changes rather than edit live state.

Practice this question →

MCQmedium

Why does GitOps encourage the use of small, frequent commits?

A.To force developers to spend more time on documentation.

B.To ensure the Git server doesn't crash.

C.To minimize the size of the Git repository.

D.To reduce the blast radius and simplify troubleshooting.

AnswerD

Small, frequent commits limit each change to a narrow, reviewable diff, so a failed reconciliation affects fewer resources. This directly reduces the blast radius and makes troubleshooting simpler, since the offending commit is isolated and can be reverted without unwinding unrelated changes.

Why this answer

Small, frequent commits limit how many resources change in a single deployment, shrinking the blast radius if something breaks and making it easier to identify which commit introduced a problem. This aligns with GitOps principles of traceability and fast rollback via git revert.

Exam trap

CGOA often tests whether candidates conflate commit size with repository performance or storage — the trap is picking an answer about Git server stability or repo size instead of recognizing that small commits are about limiting deployment blast radius and simplifying troubleshooting.

How to eliminate wrong answers

Option A is wrong because commit size has no relationship to documentation effort; documentation is a separate concern from deployment granularity. Option B is wrong because Git servers handle large commits fine — repository health is not the reason for small commits. Option C is wrong because repository size is driven by total history and binary artifacts, not commit frequency; small commits do not meaningfully reduce repo size.

Practice this question →

MCQmedium

An organization is migrating to GitOps using Argo CD. During an audit, you notice that manual changes made directly to the Kubernetes cluster via kubectl are being reverted within minutes. Which component of the GitOps pipeline is performing this action?

A.The cluster ingress controller

B.The Argo CD API server

C.The Git webhook listener

D.The Application Controller

AnswerD

The Application Controller continuously compares live cluster state against the desired state in Git and reconciles drift. When kubectl edits diverge from Git, it detects the OutOfSync difference and reapplies the manifest, reverting the manual change within its polling interval.

Why this answer

The Argo CD Application Controller is the component that continuously monitors live cluster state against the desired state in Git and performs reconciliation. When it detects drift (e.g., a manual kubectl change), and the Application has automated sync with self-heal enabled, the Application Controller re-applies the Git-defined manifests, reverting the manual change. It is the engine behind Argo CD's drift correction.

Exam trap

The trap is confusing the API server (which handles UI/API/webhooks) with the Application Controller (which performs reconciliation) — candidates often pick the API server because it is the most visible Argo CD component.

How to eliminate wrong answers

Option A is wrong because the cluster ingress controller handles inbound HTTP/HTTPS routing to services; it has no awareness of Git desired state and does not revert kubectl changes. Option B is wrong because the Argo CD API server serves the UI, CLI, and API requests, and handles authentication and RBAC, but it does not perform the reconciliation loop — that is the Application Controller's job. Option C is wrong because the Git webhook listener (part of the API server) receives webhook events from Git providers to trigger immediate refreshes, but it does not itself reconcile or revert cluster state.

Practice this question →

MCQmedium

When should you use Kustomize in a GitOps workflow?

A.To build container images.

B.To manage environment-specific overrides in a declarative way.

C.To delete all namespaces.

D.To perform load testing on the cluster.

AnswerB

Kustomize overlays let you patch a shared base manifest per environment, keeping environment-specific values such as replicas or image tags declarative and version-controlled. This avoids duplicating whole manifests or templating, which suits GitOps reconciliation where the desired state must remain plain Kubernetes YAML.

Why this answer

Kustomize is a declarative configuration customization tool that overlays environment-specific patches (replicas, image tags, resource limits, namespace) on top of a shared base without templating. In GitOps it is the standard way to keep one base and produce dev/staging/prod variants.

Exam trap

The trap is confusing Kustomize (declarative overlay rendering) with CI build tools or destructive kubectl operations, since all appear in deployment pipelines.

How to eliminate wrong answers

Option A is wrong because Kustomize does not build container images — that is the job of Docker/Buildah/Kaniko in a CI pipeline. Option C is wrong because Kustomize does not delete namespaces; it renders YAML, and destructive operations are performed by kubectl or the GitOps controller, not by Kustomize itself. Option D is wrong because load testing is a performance-engineering activity (k6, Locust, JMeter) unrelated to manifest customization.

Practice this question →

MCQeasy

Which of the following is a primary benefit of using a GitOps pull-based model over a push-based CI/CD model?

A.Automatic code compilation within the cluster.

B.Removal of the need for external access to cluster credentials.

C.Support for imperative commands.

D.Faster deployment velocity.

AnswerB

A pull-based GitOps operator runs inside the cluster and reconciles state from Git, so external CI systems never hold cluster credentials. This directly satisfies the stem's constraint by eliminating inbound access and stored kubeconfigs, shrinking the attack surface compared with push-based pipelines that require Microsoft Entra ID-authenticated external access to the API server.

Why this answer

In a pull-based GitOps model, an in-cluster agent (e.g., Argo CD, Flux) pulls desired state from Git, so external CI systems never need cluster credentials. This removes the need to store or expose kubeconfig/API credentials outside the cluster, significantly reducing the attack surface.

Exam trap

CGOA often tests the security rationale behind pull-based GitOps — the trap is choosing 'faster deployment velocity' as the primary benefit, when the defining advantage is eliminating external access to cluster credentials.

How to eliminate wrong answers

Option A is wrong because code compilation happens in CI build pipelines, not inside the cluster, and is unrelated to the pull-versus-push distinction. Option C is wrong because GitOps is fundamentally declarative; supporting imperative commands is not a benefit of the pull model and actually contradicts GitOps principles. Option D is wrong because faster deployment velocity is not inherently guaranteed by pull-based models — push models can be equally fast, and the primary pull-model benefit is security and credential isolation, not raw speed.

Practice this question →

MCQmedium

You are implementing a GitOps workflow where the desired state is stored in a private repository. The Argo CD controller requires access to this repository. What is the most secure GitOps-compliant way to provide this access?

A.Grant the cluster node broad read access to all public repositories.

B.Use an environment variable in the Argo CD container deployment manifest.

C.Create a Kubernetes Secret containing the SSH key and reference it in the repository configuration.

D.Hardcode the credentials in the Application manifest.

AnswerC

Storing the SSH deploy key in a Kubernetes Secret keeps credentials out of the Git repository and manifests, and Argo CD references that Secret in its repository configuration. This satisfies the stem's private-repository access requirement while remaining GitOps-compliant.

Why this answer

Storing the SSH private key in a Kubernetes Secret and referencing it in Argo CD's repository configuration is the GitOps-compliant and secure approach. Secrets are the native Kubernetes mechanism for sensitive data, can be encrypted at rest (with KMS or sealed-secrets), and are scoped to the Argo CD namespace with RBAC controls. This keeps credentials out of Git and out of plaintext manifests, aligning with GitOps principles of declarative, auditable, and secure state management.

Exam trap

The trap is treating convenience (environment variables or hardcoded credentials) as acceptable — the exam tests whether you know that Kubernetes Secrets are the correct native mechanism for GitOps credential management, even though Secrets are only base64-encoded by default.

How to eliminate wrong answers

Option A is wrong because granting broad read access to all public repositories is both insecure (over-privileged) and irrelevant — the repository is private, so public read access does not grant access. Option B is wrong because environment variables in a deployment manifest are visible in plaintext to anyone with pod spec read access and are easily leaked via kubectl describe or process listings. Option D is wrong because hardcoding credentials in the Application manifest commits secrets to Git, violating GitOps security principles and exposing them to anyone with repository access.

Practice this question →

MCQeasy

What is the primary role of the 'Git' repository in the GitOps cycle?

A.To monitor the health of the nodes.

B.To manage user identities.

C.To store container binary files.

D.To be the single source of truth for the desired system state.

AnswerD

Commits to the repository hold the declarative manifests defining the intended cluster configuration. Agents such as Argo CD or Flux watch it and reconcile live resources to match, so Git alone records what the system should be, satisfying the single-source-of-truth requirement.

Why this answer

In GitOps, the Git repository is the single source of truth: it holds the declarative manifests that define the desired state of the entire system. Controllers continuously compare the cluster's actual state to what Git declares and reconcile any drift. This makes Git the authoritative record for both configuration and change history.

Exam trap

CGOA often tests whether candidates conflate Git's role with that of registries, monitoring systems, or identity providers — the key is recognizing Git as the declarative source of truth, not a runtime or storage component.

How to eliminate wrong answers

Option A is wrong because node health monitoring is the job of tools like Prometheus, kubelet, and node-problem-detector, not Git. Option B is wrong because user identity management is handled by IAM, OIDC, or Kubernetes RBAC, not by a Git repository. Option C is wrong because container binary files (images) are stored in container registries like ECR or Docker Hub; Git stores manifests and code, not image layers.

Practice this question →

Multi-Selecthard

Which THREE features of Kubernetes are commonly used to support GitOps?

Select 3 answers

A.The Kubernetes API for resource management.

B.Node labels for scheduling.

C.Namespaces for configuration isolation.

D.RBAC for restricting access.

E.The cluster's internal clock synchronization.

AnswersA, C, D

The Kubernetes API provides the declarative, resource-oriented interface GitOps agents rely on: controllers continuously reconcile live cluster state against manifests stored in Git. This satisfies the stem's requirement for a commonly used supporting feature, since tools such as Argo CD and Flux operate entirely through API server reads and writes.

Why this answer

Option A is correct because GitOps tools such as Argo CD and Flux reconcile the desired state stored in Git by continuously reading and writing resources through the Kubernetes API, which is the declarative control plane interface for creating, updating, and watching objects. Option C is correct because namespaces provide logical isolation and scoping for configuration, allowing GitOps-managed manifests and their associated RBAC, quotas, and policies to be separated per team, environment, or application. Option D is correct because RBAC restricts which users and service accounts can apply or modify resources, which is essential for GitOps controllers to have least-privilege permissions to sync Git-declared state without granting broad cluster-admin access.

Option B is not a GitOps-supporting feature in this context because node labels are used by the scheduler for pod placement and do not implement declarative Git-to-cluster reconciliation. Option E is not relevant because internal clock synchronization supports time consistency for logs, certificates, and scheduling, but it is not a Kubernetes feature used to enable GitOps workflows.

Exam trap

CGOA often tests whether candidates can distinguish GitOps-relevant Kubernetes features from general cluster features — the trap is selecting node labels or clock sync, which are operationally important but play no role in declarative reconciliation.

Practice this question →

MCQeasy

Which of these is the most suitable tool to use as the 'Git' component of GitOps?

A.A standard Git repository (e.g., GitHub, GitLab).

B.A container registry.

C.A local text file on the cluster nodes.

D.A relational database.

AnswerA

A standard Git repository provides the version control, branching, pull-request review and webhook capabilities GitOps depends on. GitHub or GitLab supply the commit history and audit trail that let a reconciler detect drift and roll back, without proprietary tooling.

Why this answer

GitOps fundamentally relies on Git as the single source of truth for declarative infrastructure and application state, so a standard Git repository (GitHub, GitLab, Bitbucket, etc.) is the canonical 'Git' component. The repository stores manifests, Helm charts, and Kustomize overlays that an agent continuously reconciles against the live cluster.

Exam trap

The trap here is conflating 'Git' with any storage or artifact system — candidates may pick a container registry because it's part of the CI/CD pipeline, but GitOps specifically requires a version-controlled Git repository as the declarative source of truth.

How to eliminate wrong answers

Option B is wrong because a container registry stores OCI images, not declarative configuration — it's a delivery artifact store, not the version-controlled source of truth GitOps requires. Option C is wrong because a local text file on cluster nodes is neither versioned, distributed, nor auditable, defeating GitOps' pull-based reconciliation and rollback model. Option D is wrong because a relational database lacks Git's branching, diffing, commit history, and pull-request workflow that make GitOps declarative and reviewable.

Practice this question →

MCQhard

You are configuring an automated GitOps pipeline. How do you prevent 'drift' from occurring due to out-of-band changes?

A.By manually disabling 'kubectl' access for all users.

B.By enabling automated self-healing in the GitOps controller.

C.By storing the state in a central database instead of Git.

D.By setting up a cron job to restart the cluster daily.

AnswerB

Automated self-healing makes the GitOps controller continuously reconcile live cluster state against the desired state declared in Git. Any out-of-band change is detected as drift and automatically reverted, satisfying the requirement to prevent drift rather than merely detect it.

Why this answer

Automated self-healing in the GitOps controller continuously reconciles the live cluster state against the desired state stored in Git. When an out-of-band change (drift) is detected, the controller automatically reverts the cluster to match Git, preventing drift from persisting. This is a core GitOps principle: the controller enforces the declared state.

Exam trap

CGOA often tests the misconception that preventing drift requires restricting human access, rather than implementing automated reconciliation.

How to eliminate wrong answers

Option A is wrong because disabling kubectl access does not prevent drift from other sources (e.g., CI/CD pipelines, operators, or direct API calls) and is impractical. Option C is wrong because storing state in a central database instead of Git undermines the GitOps model, which relies on Git as the single source of truth. Option D is wrong because restarting the cluster daily does not address drift and causes unnecessary disruption.

Practice this question →

MCQmedium

An application is failing because a developer accidentally edited a ConfigMap in the cluster directly. Which GitOps feature prevents this from recurring?

A.Role-Based Access Control (RBAC).

B.Continuous reconciliation.

C.External DNS.

D.CI/CD pipeline triggers.

AnswerB

Continuous reconciliation continuously compares live cluster state against the desired state stored in Git, so any manual edit to the ConfigMap is detected and automatically reverted to the committed version. This drift correction directly satisfies the stem's requirement to prevent unauthorised direct changes recurring.

Why this answer

Continuous reconciliation is the GitOps mechanism where an agent (Argo CD, Flux) running in the cluster continuously compares the live state against the desired state declared in Git and automatically reverts any drift. If a developer manually edits a ConfigMap, the reconciler detects the divergence on its next sync cycle and restores the Git-declared value, preventing the manual change from persisting. This is the defining GitOps control that enforces Git as the single source of truth and eliminates configuration drift.

Exam trap

The trap is confusing prevention (RBAC) with correction (reconciliation) — the question asks what prevents recurrence of an already-occurring manual edit, which is drift correction, not access control.

How to eliminate wrong answers

Option A is wrong because RBAC controls who can perform actions on the API server — it can prevent a developer from editing the ConfigMap in the first place, but it does not automatically correct drift if the edit does occur (e.g., via a privileged account or a compromised credential). Option C is wrong because External DNS is a controller that synchronizes Kubernetes Service/Ingress resources with external DNS providers; it has nothing to do with reverting configuration drift. Option D is wrong because CI/CD pipeline triggers initiate builds and deployments when code changes, but they do not continuously monitor the running cluster for unauthorized manual changes — that is the reconciler's job.

Practice this question →

MCQhard

You need to ensure that no one can modify cluster resources manually. How can you implement this in a GitOps-mature organization?

A.Remove cluster-admin access from all users except the GitOps controller.

B.Install a plugin that logs all kubectl commands.

C.Add a firewall rule to block kubectl.

D.Disable the Kubernetes API server.

AnswerA

GitOps requires Git to be the sole source of truth, so removing cluster-admin rights from humans and granting write access only to the GitOps controller forces every change through pull requests. This enforces the constraint that no one can modify cluster resources manually.

Why this answer

In a GitOps-mature organization, the GitOps controller is the only entity with write access to the cluster, and all changes flow through Git. Removing cluster-admin access from all users except the GitOps controller enforces this by preventing manual modifications, ensuring that the Git repository remains the single source of truth. This is a foundational security practice in GitOps.

Exam trap

CGOA often tests the difference between detecting and preventing manual changes — logging or firewalls detect or obstruct but do not enforce the GitOps single-source-of-truth model like RBAC restrictions do.

How to eliminate wrong answers

Option B is wrong because logging kubectl commands only provides audit visibility; it does not prevent manual modifications, so it fails to meet the requirement of ensuring no one can modify resources manually. Option C is wrong because blocking kubectl via a firewall rule is ineffective — kubectl communicates over the Kubernetes API, which is typically HTTPS on port 443, and blocking it would also block legitimate API traffic; moreover, users could use other clients. Option D is wrong because disabling the Kubernetes API server would render the cluster inoperable, including for the GitOps controller itself, which needs API access to reconcile state.

Practice this question →

MCQhard

You are implementing GitOps for a legacy application. Why might this be challenging?

A.GitOps doesn't support Java applications.

B.The cluster API is too slow for legacy apps.

C.Legacy applications often lack declarative configuration files.

D.Git servers cannot store old code.

AnswerC

GitOps reconciliation depends on declarative manifests describing desired state. Legacy applications typically ship imperative install scripts, manual runbooks or undocumented configuration, so no declarative representation exists to commit. That gap is the core obstacle, forcing teams to author manifests before any controller can reconcile them.

Why this answer

GitOps depends on declarative, version-controlled manifests that describe the desired state of every resource. Legacy applications are often deployed via imperative scripts, manual console steps, or undocumented procedures, so there is no declarative artifact to put in Git. This forces teams to reverse-engineer and codify the deployment before GitOps can manage it.

Exam trap

CGOA often tests the misconception that GitOps is limited by language or cluster speed, when the real obstacle for legacy apps is the absence of declarative configuration.

How to eliminate wrong answers

Option A is wrong because GitOps is language-agnostic; Java applications are routinely managed by Argo CD and Flux via Helm charts or Kustomize overlays. Option B is wrong because Kubernetes API latency is unrelated to whether an application is legacy; the API handles all workloads uniformly. Option D is wrong because Git repositories have no age or code-vintage restriction; they store any text or binary artifact regardless of how old the application is.

Practice this question →

Multi-Selectmedium

Which TWO practices are recommended when managing Git repositories for GitOps?

Select 2 answers

A.Using directory structures to separate environmental configurations.

B.Structuring manifests logically for readability and maintenance.

C.Hardcoding all credentials in the manifest.

D.Committing direct changes to the 'main' branch.

E.Storing all environments (dev/prod) in a single file.

AnswersA, B

Separating environments into distinct directories lets each cluster reconcile only its own path, preventing a change intended for staging from being applied to production. This satisfies the recommended practice of isolating environmental configuration within a shared repository.

Why this answer

Option A is correct because using directory structures to separate environmental configurations (e.g., overlays/dev, overlays/prod or clusters/<env>) keeps each environment's desired state isolated and reviewable, which is a core GitOps practice for promoting changes safely across environments. Option B is correct because structuring manifests logically (grouping by app, namespace, or Kustomize base/overlay) improves readability, maintainability, and code review, making the Git repository a reliable source of truth for GitOps reconciliation. Option C is wrong because hardcoding credentials in manifests exposes secrets in Git history and violates GitOps security practices; secrets should be managed via Sealed Secrets, SOPS, or an external secret store.

Option D is wrong because committing direct changes to 'main' bypasses pull-request review and CI validation, undermining the auditable, declarative workflow GitOps depends on. Option E is wrong because storing all environments in a single file couples dev and prod, making it impossible to promote or roll back one environment independently and increasing the blast radius of any change.

Exam trap

CGOA often tests whether candidates recognise anti-patterns (hardcoded secrets, direct main commits, single-file multi-env) as wrong — the trap is picking 'convenient' options that violate GitOps security and separation principles.

Practice this question →

MCQeasy

A team is implementing GitOps for their infrastructure. They want to ensure that the entire system state is described in a way that can be versioned, reviewed, and automatically applied. Which characteristic of GitOps best describes the practice of storing all configuration as code in Git?

A.Procedural

B.Declarative

C.Imperative

D.Mutable

AnswerB

Declarative means the desired state is expressed as code, specifying what the system should look like rather than how to achieve it. Storing configuration as code in Git aligns with this principle because it allows versioning, review, and automated application. This is a core characteristic of GitOps, enabling the system to be described in a declarative manner.

Why this answer

The declarative characteristic of GitOps means the entire system state is described as code in Git, specifying what the system should be. This enables version control, peer review, and automated reconciliation. Storing configuration as code is a direct application of the declarative principle, making it the best description.

Exam trap

The trap here is confusing declarative with imperative, thinking that storing configuration as code means writing scripts, but GitOps uses declarative manifests.

Practice this question →

Multi-Selectmedium

An organization is implementing GitOps across its infrastructure using Kubernetes and Flux. Which TWO statements accurately describe core characteristics of the 'Automated Pull-Based Reconciliation' principle?

Select 2 answers

A.Reconciliation automatically corrects drift when actual live cluster state deviates from desired Git state.

B.The Git repository initiates an inbound SSH connection to cluster worker nodes to push manifest updates.

C.An agent deployed inside the managed cluster periodically polls the Git repository for state changes.

D.Cluster administrative credentials must be stored inside external CI system secret stores.

E.Reconciliation requires direct human approval at the terminal for every individual resource sync.

AnswersA, C

Automated pull-based reconciliation continuously compares desired Git state against live cluster state and reapplies manifests when they diverge. This self-healing behaviour corrects manual or accidental drift, which is precisely the characteristic the stem asks about.

Why this answer

Option A is correct because automated pull-based reconciliation continuously compares the desired state declared in Git with the actual live state in the cluster and automatically remediates any drift, restoring resources to the declared configuration. Option C is correct because in the pull model an in-cluster agent such as Flux's source-controller/kustomize-controller periodically fetches (polls) the Git repository and applies changes, so no inbound connection to the cluster is needed. Option B is wrong because pull-based GitOps never has Git initiate inbound SSH connections to worker nodes; the cluster agent pulls from Git instead.

Option D is wrong because the whole point of pull-based GitOps is that external CI systems do not need cluster administrative credentials, which stay inside the cluster. Option E is wrong because reconciliation is automated and continuous, not gated by manual human approval for each resource sync.

Exam trap

CGOA often tests the direction of the connection — candidates who pick 'Git pushes to the cluster' or 'credentials stored in CI' are confusing pull-based GitOps with traditional push-based CI/CD pipelines.

Practice this question →

Multi-Selectmedium

Which TWO tools are commonly associated with the 'GitOps' ecosystem?

Select 2 answers

A.Docker Desktop.

B.Nginx.

C.Prometheus.

D.Argo CD.

E.Flux.

AnswersD, E

Argo CD is a Kubernetes controller that watches Git repositories and reconciles declared manifests against live cluster state, making it a canonical GitOps delivery tool. It satisfies the ecosystem requirement by implementing pull-based continuous deployment rather than imperative pipeline pushes.

Why this answer

Argo CD (D) is a declarative, GitOps continuous-delivery controller for Kubernetes that continuously reconciles the live cluster state against manifests stored in a Git repository, making it a flagship GitOps tool. Flux (E) is likewise a CNCF GitOps toolkit that watches Git repositories and applies/reconciles Kubernetes manifests, so it is equally central to the GitOps ecosystem. Docker Desktop (A) is a local container build/run environment, Nginx (B) is a web server/reverse proxy, and Prometheus (C) is a metrics monitoring and alerting system; none of these implement Git-based declarative reconciliation, so they are not GitOps tools.

Exam trap

The trap is that candidates may associate any popular DevOps tool (Docker, Nginx, Prometheus) with GitOps because they appear in Kubernetes ecosystems, but the exam expects recognition of the specific reconciliation controllers — Argo CD and Flux — that implement the GitOps pull model.

Practice this question →

MCQmedium

In a large enterprise, why is GitOps preferred for multi-cluster environments?

A.It enables developers to bypass security controls in dev clusters.

B.It automatically scales the nodes in all clusters.

C.It eliminates the need for any monitoring tools.

D.It allows a single source of truth to manage configuration consistency across all clusters.

AnswerD

A single Git repository acts as the declarative source of truth, so every cluster reconciles to the same committed state. This eliminates configuration drift between clusters and satisfies the enterprise constraint of consistent, auditable configuration across many clusters without manual per-cluster intervention.

Why this answer

GitOps uses a single Git repository as the source of truth for all cluster configurations, enabling consistent, version-controlled management across many clusters. This ensures configuration consistency and simplifies multi-cluster operations.

Exam trap

The trap is attributing unrelated benefits (auto-scaling, security bypass, eliminating monitoring) to GitOps instead of its core value of a single source of truth for configuration consistency.

How to eliminate wrong answers

Option A is wrong because GitOps does not enable bypassing security controls; it actually enforces them through declarative policies. Option B is wrong because GitOps does not automatically scale nodes; cluster autoscaling is a separate concern. Option C is wrong because GitOps does not eliminate the need for monitoring; monitoring is still required for observability.

Practice this question →