Knowledge + Practice

Certified GitOps Associate (CGOA, CNCF/Linux Foundation) (CGOA) (CGOA) — Questions 1–75

323 questions total · 5 pages · All types, answers revealed

Take a mock exam Exam hub

Page 1 of 5

1

Multi-Selectmedium

When setting up Argo CD, which TWO components are essential to define a GitOps workflow?

Select 2 answers

A.Kubernetes Node

B.AppProject

C.Application CRD

D.Docker Registry

E.Jenkins Pipeline

AnswersB, C

AppProject provides the logical boundary that scopes which repositories, clusters and namespaces an Application may deploy to, satisfying the multi-tenancy and least-privilege constraint. Without it, Applications inherit unrestricted access, so it is essential alongside the Application resource to define a governed GitOps workflow.

Why this answer

In Argo CD, the Application CRD (option C) is essential because it defines the desired state of a deployed application by linking a source Git repository (with path and target revision) to a destination Kubernetes cluster and namespace, which is the core of the GitOps reconciliation loop. The AppProject (option B) is also essential because it provides the logical grouping and RBAC boundary that restricts which repositories, clusters, and namespaces an Application may use, enforcing multi-tenancy and security in the GitOps workflow. A Kubernetes Node (option A) is just the underlying compute host where Argo CD and workloads run; it is infrastructure, not a GitOps workflow definition.

A Docker Registry (option D) stores container images but is not required by Argo CD to define GitOps, since Argo CD syncs Kubernetes manifests from Git rather than images directly. A Jenkins Pipeline (option E) is a CI tool and is not part of Argo CD's GitOps model, which is pull-based and driven by the Application and AppProject resources.

Exam trap

CGOA often tests the confusion between Argo CD components and general Kubernetes or CI/CD tools, leading candidates to select infrastructure or CI tools instead of the specific Argo CD CRDs.

Full explanation →

2

MCQeasy

What is the purpose of the 'destination' field in an Argo CD Application manifest?

A.It defines the sync frequency.

B.It defines the user who triggered the sync.

C.It defines the Git repository URL.

D.It defines the target Kubernetes cluster and namespace.

AnswerD

The destination field specifies the target cluster's API server URL (or name) and the namespace where Argo CD deploys the application's manifests. This satisfies the stem's requirement by identifying precisely where synced resources land, separating deployment location from source repository and sync policy configuration.

Why this answer

The destination field in an Argo CD Application manifest specifies the target Kubernetes cluster (by server URL or name) and the namespace where the application's resources will be deployed. It tells Argo CD where to apply the manifests from the source repository. This is essential for multi-cluster deployments.

Exam trap

CGOA often tests the confusion between source (Git repo) and destination (cluster/namespace) fields in an Argo CD Application manifest.

How to eliminate wrong answers

Option A is wrong because sync frequency is controlled by syncPolicy (e.g., automated sync with selfHeal) or manually triggered, not by the destination field. Option B is wrong because the user who triggered a sync is recorded in audit logs or annotations, not in the destination field. Option C is wrong because the Git repository URL is defined in the source field, not destination.

Full explanation →

3

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.

Full explanation →

4

Multi-Selectmedium

You are deploying applications across multiple clusters using Argo CD. You want to implement a hub-and-spoke model where the central management cluster controls all edge clusters. Which THREE of the following are necessary to correctly configure this pattern?

Select 3 answers

A.Install Argo CD control plane components on every edge cluster

B.Configure the 'server.enable.proxy' flag in the hub cluster

C.Ensure the service account for Argo CD has cluster-admin permissions on target clusters

D.Define Application projects to restrict cluster access

E.Create Argo CD cluster secrets in the management cluster namespace

AnswersC, D, E

Argo CD's management cluster must authenticate to each spoke cluster's API server and create or modify resources there. Cluster-admin permissions on the target clusters grant that authority, enabling the hub to deploy and reconcile applications across all edge clusters.

Why this answer

In a hub-and-spoke Argo CD topology, the hub cluster runs the Argo CD control plane and manages remote edge clusters as external targets, so option C is correct because the Argo CD application-controller's service account (or the credential stored in the cluster secret) must have sufficient RBAC—typically cluster-admin or an equivalent scoped role—on each target cluster to create, update, and delete the deployed resources. Option D is correct because Argo CD AppProjects are the mechanism that restricts which clusters (destinations) and namespaces an Application may target, enforcing multi-tenancy and preventing a project from deploying to unauthorized edge clusters. Option E is correct because remote clusters are registered by creating cluster Secrets (labeled argocd.argoproj.io/secret-type: cluster) in the Argo CD namespace on the hub, containing the target server URL and credentials, which is how the hub knows and authenticates to each spoke.

Option A is incorrect because installing the Argo CD control plane on every edge cluster describes a distributed/standalone model, not hub-and-spoke, where only the hub runs the control plane. Option B is incorrect because there is no 'server.enable.proxy' flag required for this pattern; remote access is handled through cluster Secrets and the argocd-server/application-controller, not such a flag.

Exam trap

CGOA often tests whether candidates confuse the hub-and-spoke model with a multi-instance Argo CD deployment, so the trap is selecting 'install Argo CD on every cluster' as if it were required for centralized management.

Full explanation →

5

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.

Full explanation →

6

Multi-Selecthard

Which THREE of the following are potential risks of ignoring drift in a GitOps environment?

Select 3 answers

A.Reduced storage usage

B.The Git repo becomes outdated relative to the cluster

C.Application instability due to unexpected configuration

D.Security vulnerabilities due to unmanaged manual changes

E.Increased deployment speed

AnswersB, C, D

When drift is ignored, the cluster diverges from the manifests while Git still holds the last committed revision, so the repository no longer reflects reality. The declared desired state becomes stale relative to what actually runs, undermining Git's role as the single source of truth.

Why this answer

Option B is correct because when drift occurs, manual changes are made directly to the cluster and never reflected back into Git, so the Git repository no longer represents the actual desired state and becomes outdated relative to the running cluster. Option C is correct because unmanaged manual changes can introduce unexpected configuration that conflicts with the declared manifests, leading to application instability, inconsistent behavior, or failed reconciliations. Option D is correct because manual changes bypass the reviewed, version-controlled Git workflow, so security-relevant settings (e.g., exposed ports, weakened RBAC, disabled TLS) can be introduced without audit or approval, creating unmanaged vulnerabilities.

Option A is incorrect because ignoring drift does not reduce storage usage; drift typically adds untracked resources rather than freeing space. Option E is incorrect because ignoring drift does not increase deployment speed; it undermines the automated, reliable GitOps pipeline and often causes slower, error-prone remediation.

Exam trap

CGOA often tests whether candidates can distinguish genuine drift risks from unrelated operational metrics, so the trap is selecting plausible-sounding but irrelevant options like storage savings or deployment speed.

Full explanation →

7

MCQeasy

In the context of GitOps, what is 'Configuration Drift'?

A.A security vulnerability in the container image.

B.The movement of traffic between blue and green environments.

C.The difference between the cluster state and the Git repository state.

D.The time taken for a Git commit to reach the production cluster.

AnswerC

Configuration drift describes divergence between the live cluster state and the desired state declared in Git, the single source of truth. GitOps tooling such as Argo CD or Flux continuously reconciles this difference, detecting when manual changes or failures push the cluster away from the committed manifests.

Why this answer

Configuration drift in GitOps is the divergence between the desired state declared in the Git repository and the actual state running in the cluster. GitOps controllers such as Argo CD or Flux continuously reconcile the cluster toward Git, and drift is detected when the live state no longer matches the declared manifests — for example, after a manual kubectl edit or an out-of-band change.

Exam trap

CGOA often tests the distinction between drift (state divergence from Git) and deployment latency or security scanning, so candidates who see 'difference' and 'cluster' may pick a timing or vulnerability answer instead of the state-mismatch definition.

How to eliminate wrong answers

Option A is wrong because a container image vulnerability is a security concern addressed by image scanning (e.g., Trivy, Clair), not by the GitOps concept of drift. Option B is wrong because traffic movement between blue and green environments is a deployment strategy (blue/green) and is unrelated to state divergence. Option D is wrong because the time for a commit to reach production is deployment latency or sync time, not drift; drift is about state mismatch, not timing.

Full explanation →

8

MCQhard

When implementing DevSecOps within a GitOps workflow, where should the automated policy enforcement (like OPA/Gatekeeper) occur?

A.During the Git commit process using local pre-commit hooks.

B.In the CI pipeline during the image scanning phase.

C.At the Kubernetes API server using an Admission Controller like OPA Gatekeeper.

D.By manually reviewing the Git diffs before merging the pull request.

AnswerC

OPA Gatekeeper runs as a validating admission controller on the Kubernetes API server, so every manifest is evaluated against policy before persistence. This enforces policy at the cluster's control point, catching GitOps-applied resources regardless of source repository.

Why this answer

OPA/Gatekeeper runs as a Kubernetes admission controller (ValidatingAdmissionWebhook) that intercepts API server requests before objects are persisted. This enforces policy at the cluster boundary regardless of whether the change came from GitOps, kubectl, or a rogue controller — making it the authoritative enforcement point in a DevSecOps GitOps workflow.

Exam trap

CGOA often tests the misconception that CI scanning or pre-commit hooks are sufficient policy enforcement — the authoritative, non-bypassable enforcement point is the Kubernetes admission controller (OPA Gatekeeper).

How to eliminate wrong answers

Option A is wrong because local pre-commit hooks are client-side and easily bypassed with --no-verify; they provide developer feedback but are not authoritative enforcement. Option B is wrong because CI image scanning catches vulnerabilities in container images but does not enforce Kubernetes manifest policy (e.g., disallowing hostNetwork or privileged pods) at admission time. Option D is wrong because manual PR review is a human process that does not scale and cannot guarantee enforcement — a merged manifest with a policy violation would still be applied by the GitOps agent.

Full explanation →

9

Multi-Selecthard

A platform team is designing a GitOps workflow and wants to avoid common failure modes that undermine the model's guarantees. Which TWO practices undermine a GitOps workflow? (Choose two.)

Select 2 answers

A.Storing separate configuration for each environment in distinct directories within the same repository, managed with overlays.

B.Requiring pull-request review and automated policy checks before merging changes to the configuration repository.

C.Using long-lived cluster-admin credentials in an external CI pipeline to push manifests into production clusters.

D.Allowing engineers to apply emergency changes directly with kubectl and never backfilling those changes into Git.

E.Enabling automated sync with self-heal so the agent continuously corrects divergence from the declared state.

AnswersC, D

Push-based deployment with highly privileged, long-lived credentials reintroduces exactly the security and audit weaknesses GitOps is meant to remove. The cluster's desired state is applied from outside rather than reconciled in-cluster, and a compromised pipeline can alter production directly. This pattern also makes drift detection less meaningful because the pipeline, not Git, is the effective deployment authority.

Why this answer

GitOps depends on Git being the authoritative, continuously reconciled source of truth. Uncommitted kubectl changes and push-based pipelines using long-lived privileged credentials both bypass that authority, leaving the cluster and the repository out of sync and weakening auditability. Environment overlays, pull-request review, and automated self-heal are recommended practices that reinforce the model rather than undermine it.

Exam trap

The trap here is assuming that any automated deployment is GitOps, when push-based pipelines with long-lived cluster credentials actually contradict the pull-based reconciliation model.

Full explanation →

10

MCQmedium

What does the term 'Self-Healing' mean in a GitOps context?

A.The application automatically updates its own code

B.The cluster automatically reboots upon failure

C.The system automatically restores the desired state if someone manually modifies the cluster

D.The database automatically backs itself up

AnswerC

Self-healing means the GitOps controller continuously reconciles live cluster state against the declared desired state in Git. When a manual change drifts the cluster, the controller detects the divergence and automatically reverts it, restoring the declared configuration without human intervention. This satisfies the stem's requirement of automatic restoration after manual modification.

Why this answer

Self-healing in GitOps refers to the operator's ability to detect when the live cluster state diverges from the desired state stored in Git and automatically restore the desired state. If someone manually edits or deletes a resource, the operator reverts the change to match Git. This enforces Git as the single source of truth and prevents configuration drift.

Exam trap

CGOA often tests the difference between self-healing (reverting cluster drift to match Git) and other automated recovery concepts like pod restarts or node reboots, catching candidates who pick a broader interpretation.

How to eliminate wrong answers

Option A is wrong because self-healing does not modify application source code; it reconciles infrastructure and configuration state, not application logic. Option B is wrong because rebooting a cluster is a node-level recovery action, not what GitOps self-healing means — self-healing operates at the resource reconciliation level. Option D is wrong because database backups are a data-protection concern handled by backup tools, not by GitOps reconciliation.

Full explanation →

11

MCQeasy

What is the primary benefit of a 'pull' deployment model compared to a 'push' model in GitOps?

A.Support for non-Kubernetes platforms

B.Elimination of Kubernetes manifests

C.Reduced need for inbound firewall access to the cluster

D.Faster application builds

AnswerC

In a pull model the in-cluster agent initiates outbound connections to the Git repository or controller, so no inbound firewall rules or exposed endpoints are needed. This directly satisfies the reduced inbound access requirement compared with push-based deployments.

Why this answer

In a pull-based GitOps model, an in-cluster agent (e.g., Argo CD or Flux) continuously reconciles the desired state from Git with the live cluster. Because the agent initiates outbound connections to Git and the cluster does not need to accept inbound connections from an external CI/CD system, the need for inbound firewall access to the cluster is significantly reduced — a major security and operational benefit.

Exam trap

CGOA often tests the misconception that pull-based GitOps eliminates manifests or speeds up builds — the trap is missing that the core benefit is the inverted network trust direction (no inbound access to the cluster).

How to eliminate wrong answers

Option A is wrong because GitOps pull models are not inherently about supporting non-Kubernetes platforms — the pull model is most commonly associated with Kubernetes reconciliation, and non-K8s support is a separate concern. Option B is wrong because Kubernetes manifests are still required in GitOps; the pull model does not eliminate manifests, it just changes who applies them (the in-cluster agent rather than an external pipeline). Option D is wrong because faster application builds relate to CI pipeline speed, not the deployment model — pull vs. push affects deployment/reconciliation, not build performance.

Full explanation →

12

MCQmedium

What is the role of a 'Webhook' in a GitOps setup?

A.To store encrypted credentials

B.To inform the operator of a change in the Git repository

C.To scan container images for vulnerabilities

D.To automatically approve pull requests

AnswerB

A webhook is an HTTP callback the Git host fires on push events, prompting the operator to reconcile immediately rather than waiting for its polling interval. This satisfies the stem's requirement to inform the operator of a repository change, enabling near-real-time sync.

Why this answer

A webhook in a GitOps setup is a notification mechanism: the Git provider (GitHub, GitLab, Bitbucket) sends an HTTP POST to the operator's endpoint whenever a push, merge, or tag occurs, prompting the operator to reconcile immediately. This reduces the latency between a Git commit and cluster convergence compared to relying solely on periodic polling.

Exam trap

The trap is confusing webhooks with credential management or CI scanning — candidates see 'webhook' and think of secrets or security tooling, missing that its role is purely event notification to trigger reconciliation.

How to eliminate wrong answers

Option A is wrong because credential storage is handled by Kubernetes Secrets, external secret managers (Vault, Sealed Secrets), or SOPS — webhooks transmit event notifications, not secrets. Option C is wrong because image vulnerability scanning is performed by dedicated tools like Trivy, Clair, or Grype, often integrated into CI, not by Git webhooks. Option D is wrong because pull request approval is a Git provider policy feature (branch protection, required reviewers), not something a webhook to the GitOps operator does — the operator reacts to merged changes, it does not approve PRs.

Full explanation →

13

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.

Full explanation →

14

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.

Full explanation →

15

MCQmedium

You notice your GitOps operator is performing too many API calls to the Kubernetes API server. What is the most likely configuration issue?

A.The sync policy 'syncPeriod' is set too low.

B.The Git repo is too large.

C.The operator has too many permissions.

D.The cluster is running too many pods.

AnswerA

A low syncPeriod forces the operator to reconcile and poll the Kubernetes API far more frequently than needed, inflating request volume. Raising syncPeriod reduces polling frequency while webhook-driven reconciliation still applies changes promptly, cutting API server load.

Why this answer

The 'syncPeriod' (or reconciliation interval) controls how often the GitOps operator polls Git and the cluster for drift. If it is set too low (e.g., every few seconds), the operator makes excessive API calls to the Kubernetes API server, causing load and potential throttling. Increasing the interval reduces API pressure.

Exam trap

CGOA often tests the misconception that Git repo size or cluster pod count drives API call volume, when the real cause is an overly aggressive syncPeriod (reconciliation interval) set too low.

How to eliminate wrong answers

Option B is wrong because a large Git repo affects Git fetch/render time, not Kubernetes API call volume — the operator still only applies manifests, and repo size does not drive API call frequency. Option C is wrong because excessive permissions do not cause more API calls; permissions affect what the operator can do, not how often it polls. Option D is wrong because running many pods increases cluster load generally but does not directly cause the GitOps operator to make more API calls — the operator's call rate is governed by its sync configuration.

Full explanation →

16

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.

Full explanation →

17

MCQhard

When troubleshooting a Kyverno policy, which command should you use to check if a specific resource complies with the policy?

A.kubectl get policies

B.kyverno test

C.kubectl describe policy

D.kyverno apply

AnswerD

kyverno apply runs policy rules against given resource manifests locally, reporting pass or fail per resource without needing a cluster. This directly satisfies the stem's requirement to check whether a specific resource complies with a Kyverno policy.

Why this answer

The 'kyverno apply' command is used to apply Kyverno policies to a given resource or set of resources and check compliance. It simulates policy enforcement and reports whether the resource complies with the specified policies. This is the correct command for troubleshooting whether a specific resource adheres to a policy.

Exam trap

CGOA often tests Kyverno CLI commands, and candidates may confuse 'kyverno apply' with 'kyverno test'; the former checks resource compliance, while the latter runs policy unit tests.

How to eliminate wrong answers

Option A is wrong because 'kubectl get policies' is not a valid command; Kyverno policies are custom resources, typically retrieved with 'kubectl get clusterpolicy' or 'kubectl get policy'. Option B is wrong because 'kyverno test' is used to run unit tests against policies, not to check a specific resource's compliance. Option C is wrong because 'kubectl describe policy' is not a standard command for Kyverno policies; you would use 'kubectl describe clusterpolicy'.

Full explanation →

18

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.

Full explanation →

19

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.

Full explanation →

20

MCQhard

What is the purpose of a 'Kustomization' resource in a GitOps workflow?

A.To dynamically customize and patch manifests for different environments

B.To perform load testing on the API server

C.To provide a secure shell into pods

D.To manage database migrations

AnswerA

A Kustomization resource applies overlays and patches to base manifests, producing environment-specific output without duplicating YAML. This dynamic customisation satisfies the stem's requirement by enabling the same base to serve development, staging and production environments.

Why this answer

A Kustomization resource (from Kustomize) defines how to customize and patch a set of base Kubernetes manifests for different environments — for example, overlaying a production replica count, image tag, or ConfigMap without duplicating YAML. It specifies resources, patches, name prefixes, and common labels, and is consumed natively by kubectl -k and by Argo CD/Flux. This makes it a core tool for environment-specific configuration in GitOps.

Exam trap

CGOA often tests Kustomize's role as a manifest-customization tool; candidates may confuse it with Helm or with runtime tooling, forgetting that Kustomize is purely a YAML transformation layer with no templating engine.

How to eliminate wrong answers

Option B is wrong because load testing the API server is unrelated to Kustomize; that would be handled by tools like k6, Locust, or hey, not a manifest-customization resource. Option C is wrong because providing a secure shell into pods is the function of kubectl exec or SSH-based debugging tools, not Kustomize. Option D is wrong because database migrations are handled by tools like Flyway, Liquibase, or application-level migration jobs — Kustomize only transforms Kubernetes YAML and has no database awareness.

Full explanation →

21

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.

Full explanation →

22

MCQmedium

In ArgoCD, what does the 'Revision' field in an Application manifest represent?

A.The number of times the app has synced

B.The ArgoCD version

C.The specific git hash or branch being tracked

D.The version of the Helm chart

AnswerC

The Revision field records the exact Git commit hash or branch ArgoCD currently tracks, satisfying the requirement to identify the deployed source state. It pins the manifest to a precise revision, enabling ArgoCD to detect drift and sync the cluster to that committed configuration.

Why this answer

In an ArgoCD Application manifest, spec.source.targetRevision (commonly surfaced as the Revision field) identifies the exact Git commit SHA, branch, or tag that ArgoCD tracks for the desired state. It is the pointer into the source repository, not a counter or a version of ArgoCD or Helm. When ArgoCD syncs, it resolves this revision to a concrete commit and compares it against the live cluster state.

Exam trap

CGOA often tests the misconception that 'Revision' is a sync counter or a tool version, when it is actually the Git ref/commit pointer that defines desired state.

How to eliminate wrong answers

Option A is wrong because ArgoCD does not store a sync-count integer in the Application spec; sync history is tracked separately in status.history entries with revision and timestamp. Option B is wrong because the ArgoCD server version is a deployment property (image tag, argocd version command), not a field in an Application manifest. Option D is wrong because the Helm chart version is expressed via targetRevision when the source is a Helm repo, or via the chart's version in the source; the Revision field itself is the Git ref/commit, not a chart version.

Full explanation →

23

MCQhard

What is the purpose of a 'Sync Window' in Argo CD?

A.To increase the size of the Git repo

B.To limit when automated syncs occur

C.To prevent users from logging in

D.To optimize network speed

AnswerB

A Sync Window defines a schedule during which automated syncs are permitted, blocking them outside those hours. This satisfies the constraint of controlling deployment timing, so reconciliation cannot apply changes during restricted periods such as peak traffic or change freezes.

Why this answer

A Sync Window in Argo CD restricts automated syncs to defined time ranges, preventing deployments during sensitive periods such as business hours, change freezes, or peak traffic. It is configured with a schedule (cron-like), duration, and optional time zone, and applies to Applications via selectors.

Exam trap

CGOA often tests Sync Windows as a scheduling control — the trap is confusing them with RBAC or performance features because the name suggests broader access control.

How to eliminate wrong answers

Option A is wrong because Sync Windows have no effect on Git repository size — they only gate when sync operations may run. Option C is wrong because Sync Windows do not affect authentication or login; user access is governed by RBAC and SSO configuration. Option D is wrong because Sync Windows do not optimise network throughput — they are a scheduling control, not a performance feature.

Full explanation →

24

Multi-Selecthard

Which THREE of the following are necessary to prevent 'Secret Sprawl' in a multi-cluster environment? (Select three)

Select 3 answers

A.Using External Secrets Operator to sync secrets to specific namespaces.

B.Using a dedicated Secret Management system (e.g., HashiCorp Vault).

C.Applying RBAC policies to ensure only specific apps can access secrets.

D.Granting 'cluster-admin' to the GitOps operator service account.

E.Storing encrypted secrets in the Git repository.

AnswersA, B, C

External Secrets Operator pulls from an external store and materialises Kubernetes Secrets only into the namespaces that need them, rather than replicating credentials cluster-wide. This narrows each secret's blast radius, directly limiting the sprawl the scenario describes across multiple clusters.

Why this answer

Option A is correct because the External Secrets Operator (ESO) pulls secrets from an external provider and syncs them only into the specific namespaces that need them, eliminating the practice of duplicating or scattering secret copies across every cluster and namespace. Option B is correct because a dedicated secret management system such as HashiCorp Vault (or AWS Secrets Manager, Azure Key Vault) provides a single authoritative source of truth with centralized lifecycle, rotation, and auditing, which is the core defense against secret sprawl. Option C is correct because RBAC policies scoped to specific ServiceAccounts and namespaces ensure only the intended applications can read a given secret, preventing the broad, uncontrolled access that fuels sprawl.

Option D is not correct because granting cluster-admin to the GitOps operator service account massively over-privileges it and worsens the blast radius rather than preventing secret sprawl. Option E is not correct because storing secrets in Git—even encrypted—still proliferates copies across repositories and clusters and is not a substitute for a centralized secret management system with controlled sync and access.

Exam trap

CGOA often tests the misconception that encrypting secrets in Git (SOPS/Sealed Secrets) is sufficient to prevent sprawl, when the exam expects a dedicated secret manager plus scoped sync plus RBAC.

Full explanation →

25

MCQhard

When using Argo CD, how do you handle applications that require resources to be created in a specific order (e.g., CRDs before Operators)?

A.Use multiple Git repositories.

B.Disable automated sync and run it twice.

C.Use syncWaves annotations.

D.Use a single massive YAML file.

AnswerC

Sync-wave annotations assign each resource a wave number; Argo CD applies lower-numbered waves and waits for them to become healthy before proceeding, so CRDs are established before the Operators that depend on them are created.

Why this answer

Argo CD supports sync waves via the argocd.argoproj.io/sync-wave annotation, which lets you assign an integer wave number to each resource. Argo CD applies resources in ascending wave order, waiting for each wave to become healthy before proceeding to the next. This is the canonical way to ensure CRDs are applied before the Operators or custom resources that depend on them.

Exam trap

The trap is assuming that file order or repository structure controls apply order — Argo CD ignores YAML file ordering and requires explicit sync-wave annotations to sequence resources.

How to eliminate wrong answers

Option A is wrong because splitting manifests across multiple Git repositories does not control apply order — Argo CD still syncs each Application independently and provides no cross-repo ordering guarantee. Option B is wrong because disabling automated sync and manually running sync twice is a fragile workaround that does not guarantee CRDs are established before dependent resources are applied. Option D is wrong because a single massive YAML file does not enforce ordering — kubectl/Argo CD apply order within a file is not guaranteed to match the file's textual order.

Full explanation →

26

MCQmedium

What is an 'Image Updater' in the GitOps ecosystem?

A.A tool to compress images

B.A tool to clean up old images in the registry

C.A tool to scan images for vulnerabilities

D.A controller that updates image tags in Git

AnswerD

An Image Updater watches registries for new tags and commits the updated image reference back into the Git manifests, so the GitOps operator then reconciles it. This matches the stem: a controller that updates image tags in Git, not the cluster directly.

Why this answer

An Image Updater in GitOps is a controller that monitors container registries for new image versions and automatically updates the corresponding image tags in Git repositories. This ensures that the desired state in Git reflects the latest available images, enabling automated deployments through GitOps workflows. Tools like Argo CD Image Updater and Flux's Image Automation Controller implement this pattern by committing changes to Git, which are then synced to the cluster.

Exam trap

CGOA often tests the misconception that an Image Updater is a security or optimization tool, confusing it with image scanning or cleanup utilities, rather than a GitOps automation component that updates Git manifests.

How to eliminate wrong answers

Option A is wrong because image compression is not a function of an Image Updater; it is typically handled by build tools or registries to reduce storage and transfer size. Option B is wrong because cleaning up old images in a registry is a registry maintenance task, often performed by garbage collection policies, not by an Image Updater. Option C is wrong because vulnerability scanning is performed by dedicated security tools like Trivy or Clair, not by an Image Updater.

Full explanation →

27

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.

Full explanation →

28

MCQmedium

You are troubleshooting a multi-cluster Argo CD deployment where the 'staging' cluster is healthy but 'production' cluster is 'OutOfSync' despite having the same manifest source. Why might this happen?

A.The production cluster has a newer version of the Kubernetes API.

B.A manual 'kubectl apply' was performed on the production cluster.

C.The 'staging' cluster is using a different Argo CD instance.

D.The Git repo is only cloned to the staging cluster.

AnswerB

A manual `kubectl apply` on production mutates live resources outside Git, so Argo CD's diff detects drift between the desired manifest and actual cluster state, reporting `OutOfSync`. The staging cluster remains untouched and healthy, satisfying the stem's constraint that identical manifest sources yield divergent sync statuses.

Why this answer

Argo CD determines sync status by comparing the desired state in Git with the live state in the cluster. If someone runs kubectl apply directly on the production cluster, the live state diverges from Git, so Argo CD reports OutOfSync even though the manifest source is identical. The staging cluster remains healthy because its live state still matches Git.

Exam trap

CGOA often tests the core GitOps principle that the cluster's live state must match Git — the trap is blaming the Git repo or Argo CD instance instead of recognising manual drift as the cause of OutOfSync.

How to eliminate wrong answers

Option A is wrong because a newer Kubernetes API version on production would not by itself cause OutOfSync if the manifests are compatible; Argo CD compares desired vs live state, not API versions. Option C is wrong because using a different Argo CD instance for staging would not explain production being OutOfSync — each instance compares its own cluster to Git. Option D is wrong because Argo CD does not 'clone the repo to the cluster'; it fetches from Git and applies to the cluster, so repo cloning location is irrelevant.

Full explanation →

29

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.

Full explanation →

30

MCQhard

Your organization uses a 'Git-branch-per-environment' strategy. You notice that hotfixes applied to the 'production' branch are being overwritten by automatic merges from the 'staging' branch. Which GitOps promotion pattern should you adopt to prevent this drift?

A.Enable Argo CD 'automated.allowEmpty' sync options.

B.Switch to a repository structure using Kustomize overlays with a single branch.

C.Implement an automated CI job to force push the staging branch to production.

D.Use Argo CD ApplicationSets with a 'git' generator to deploy only from the main branch.

AnswerB

Kustomize overlays with a single branch separate environment-specific configuration from shared base manifests, so promotion patches are applied declaratively rather than merged across branches. This prevents staging merges from overwriting production hotfixes, eliminating the drift the branch-per-environment strategy caused.

Why this answer

A single-branch repository with Kustomize overlays (B) separates environment-specific configuration (replicas, image tags, resource limits) into overlay directories while sharing a common base, so hotfixes applied to production are not overwritten by staging merges. Argo CD then syncs each overlay to its target cluster, eliminating branch-merge drift. This is the recommended GitOps promotion pattern for avoiding cross-branch overwrites.

Exam trap

CGOA often tests whether candidates recognize branch-per-environment as the root cause of drift and know that overlay-based promotion (Kustomize/Helm) is the fix, rather than reaching for Argo CD sync flags that do not address the merge problem.

How to eliminate wrong answers

Option A is wrong because 'automated.allowEmpty' only permits syncing an application when the rendered manifests are empty — it does nothing to prevent staging merges from overwriting production hotfixes. Option C is wrong because force-pushing staging to production destroys production-only commits and is a destructive anti-pattern, not a promotion strategy. Option D is wrong because ApplicationSets with a git generator deploy from branches/directories but do not by themselves solve the overwrite problem if production and staging still share a merge path; the root issue is branch-per-environment, which must be replaced by overlay-based promotion.

Full explanation →

31

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.

Full explanation →

32

MCQmedium

An ArgoCD application is configured with 'SelfHeal' set to true. If a developer manually modifies a Deployment's replica count via kubectl, what happens?

A.ArgoCD reverts the change to match the Git state

B.The change is permanently accepted

C.ArgoCD flags the app as 'OutOfSync' but waits for manual intervention

D.The manual change is merged into Git

AnswerA

SelfHeal makes ArgoCD continuously compare live state against Git and reconcile divergence automatically. The manual replica change is detected as OutOfSync, so ArgoCD reapplies the Git-declared replica count, reverting the kubectl edit without human intervention.

Why this answer

When ArgoCD's SelfHeal is enabled, it automatically reconciles the live cluster state with the desired state in Git. If a developer manually changes a Deployment's replica count via kubectl, ArgoCD detects the drift and reverts the change to match Git. This ensures the Git repository remains the single source of truth.

Exam trap

The trap is assuming that manual changes are either accepted or require manual sync; candidates might forget that SelfHeal automatically reverts drift without human intervention.

How to eliminate wrong answers

Option B is wrong because SelfHeal actively reverts manual changes; they are not permanently accepted. Option C is wrong because while ArgoCD would flag the app as OutOfSync, SelfHeal triggers automatic sync without waiting for manual intervention. Option D is wrong because ArgoCD does not merge manual changes into Git; it only applies Git state to the cluster.

Full explanation →

33

MCQmedium

During a blue-green deployment, what is the primary role of the traffic manager (e.g., Istio or Nginx Ingress)?

A.To build the container image.

B.To monitor the Git repository for changes.

C.To split traffic between versions to reduce risk.

D.To store application logs.

AnswerC

The traffic manager controls the routing layer, shifting a defined proportion of requests from the blue version to the green version. This gradual split limits the blast radius of a faulty release, satisfying the deployment's need to reduce risk during cutover.

Why this answer

In a blue-green deployment, the traffic manager (e.g., Istio, Nginx Ingress) is responsible for routing and splitting traffic between the blue (current) and green (new) versions. This allows controlled exposure of the new version, enabling canary testing or immediate rollback if issues arise, thereby reducing deployment risk. It does not build images, monitor Git, or store logs.

Exam trap

CGOA often tests the specific responsibility of the traffic manager in blue-green deployments — candidates may confuse it with CI/CD components like image builders or Git monitors.

How to eliminate wrong answers

Option A is wrong because building container images is the role of a CI system like Jenkins or GitLab CI, not the traffic manager. Option B is wrong because monitoring the Git repository is the function of a GitOps operator such as Argo CD or Flux, not the ingress controller. Option D is wrong because log storage is handled by logging stacks (e.g., ELK, Loki), not the traffic manager.

Full explanation →

34

MCQeasy

Why is 'Git' considered the 'source of truth' in GitOps?

A.Because it acts as the single point of record for the desired system state.

B.Because Git stores all application logs.

C.Because it is the only tool that supports branching.

D.Because Git automatically runs the applications.

AnswerA

Git stores the declarative desired state of the system, and GitOps agents continuously reconcile live clusters against that committed state. Every change flows through Git, making it the single point of record and audit, which is why it is the source of truth.

Why this answer

In GitOps, Git is the source of truth because it stores the declarative desired state of the entire system—manifests, configs, and policies—as versioned, reviewable commits. The GitOps controller continuously reconciles the live cluster to match what Git declares, so Git is the authoritative record. It does not store logs, is not the only tool with branching, and does not run applications itself.

Exam trap

CGOA often tests whether candidates conflate Git's role as a versioned declarative store with runtime or logging functions, so remember Git holds desired state—not logs, not execution.

How to eliminate wrong answers

Option B is wrong because Git stores source code and manifests, not application runtime logs; logs live in logging backends like Loki, Elasticsearch, or CloudWatch. Option C is wrong because branching is a common feature of many VCS and even non-VCS tools; it is not unique to Git and is not why Git is the source of truth. Option D is wrong because Git is a version control system, not an execution runtime; the GitOps controller (Argo CD, Flux) performs the deployment, not Git.

Full explanation →

35

MCQhard

You are using Flux with Kustomize. You want to apply different configurations for production and staging, but both use the same base manifests. Which Kustomize feature allows this?

A.Post-build variables

B.Overlays

C.Flux Kustomization resource

D.Helm charts

AnswerB

Overlays let a shared base hold common manifests while each environment's overlay patches only the differing fields, such as replicas or image tags. This satisfies the stem's constraint of one base reused across production and staging without duplication.

Why this answer

Kustomize overlays let you layer environment-specific customisations (replicas, image tags, patches, config) on top of a shared base without duplicating manifests. Flux's Kustomization resource points at the overlay path for each environment, so production and staging share the same base while diverging only where needed.

Exam trap

The trap is confusing the Flux Kustomization CRD (the GitOps delivery resource) with Kustomize overlays (the templating feature) — the question asks which Kustomize feature, not which Flux resource.

How to eliminate wrong answers

Option A is wrong because post-build variables are a Flux feature for substituting values into the rendered output at apply time — they do not provide the base/overlay composition model Kustomize uses. Option C is wrong because the Flux Kustomization resource is the Flux CRD that tells Flux which path to reconcile; it is the delivery mechanism, not the Kustomize feature that enables environment-specific configuration. Option D is wrong because Helm charts are a separate templating system; while Flux can reconcile HelmReleases, the question specifies Kustomize and asks for the Kustomize feature that enables base-plus-environment customisation.

Full explanation →

36

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.

Full explanation →

37

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.

Full explanation →

38

Multi-Selectmedium

Which THREE of the following items are commonly found in a Flux 'GitRepository' manifest?

Select 3 answers

A.Git reference (branch/tag)

B.Reconciliation interval

C.Kubernetes node labels

D.Repository URL

E.Database password

AnswersA, B, D

A Flux GitRepository manifest must declare which revision to reconcile, so the `spec.ref` field specifies the Git reference — a branch name such as `main` or a tag such as `v1.2.0`. This satisfies the stem's requirement for a Git reference, since Flux cannot poll a repository without knowing the target revision.

Why this answer

Option A (Git reference such as branch/tag) is correct because a Flux GitRepository manifest uses the spec.ref field to specify which branch, tag, or commit (e.g., ref: {branch: main}) the source controller should track. Option B (Reconciliation interval) is correct because the manifest includes spec.interval, which tells the source-controller how often to poll the Git remote for changes (e.g., interval: 1m). Option D (Repository URL) is correct because spec.url is a required field that points to the Git repository (e.g., https://github.com/org/repo.git or ssh://git@github.com/org/repo.git).

Option C (Kubernetes node labels) is not part of a GitRepository manifest; node labels belong to Node objects and are unrelated to source definitions. Option E (Database password) is not included; secrets like credentials are referenced indirectly via spec.secretRef, and a plaintext password would never appear in the manifest.

Exam trap

CGOA often tests whether candidates confuse source configuration fields (URL, ref, interval) with unrelated Kubernetes constructs like node labels or application secrets, causing them to select options that belong to different resource types.

Full explanation →

39

MCQeasy

What is the primary function of an 'Admission Controller' in a GitOps-based DevSecOps workflow?

A.To build container images.

B.To validate and enforce policies on cluster resources before they are persisted.

C.To monitor application logs for errors.

D.To trigger the CI/CD pipeline.

AnswerB

Admission controllers intercept API server requests after authentication and authorisation but before etcd persistence, so they can reject or mutate manifests that violate security policy. This satisfies the constraint of preventing non-compliant resources from ever being persisted, rather than detecting them after deployment.

Why this answer

Admission Controllers are Kubernetes API server plugins that intercept requests to create, modify, or delete resources after authentication/authorization but before the object is persisted to etcd. In a GitOps DevSecOps workflow, they enforce policy-as-code (e.g., OPA Gatekeeper, Kyverno) so that only compliant manifests—matching what Git declares—ever reach the cluster. This makes them the enforcement point for security guardrails, not a build or monitoring tool.

Exam trap

CGOA often tests whether candidates confuse admission controllers (pre-persistence policy enforcement) with CI build steps or runtime monitoring, so any option mentioning image builds or log analysis is a distractor.

How to eliminate wrong answers

Option A is wrong because building container images is the job of a CI system (e.g., Jenkins, GitHub Actions, Tekton), not the Kubernetes admission chain. Option C is wrong because log monitoring is performed by observability stacks (Fluentd, Prometheus, Loki), which operate after resources are running, not before persistence. Option D is wrong because triggering the CI/CD pipeline is the role of Git webhooks or CI orchestrators reacting to commits, not the admission controller.

Full explanation →

40

MCQmedium

A cluster is flagged as 'OutOfSync' in Argo CD. What does this status specifically indicate?

A.The live state in the Kubernetes cluster deviates from the version-controlled manifest.

B.The Git repository contains a syntax error in the YAML files.

C.The Kubernetes API server is unreachable.

D.The cluster has run out of memory or CPU resources.

AnswerA

OutOfSync compares the desired manifest stored in Git against the live objects in the cluster. When the running resources differ—through manual kubectl edits, drift or an unapplied commit—Argo CD flags the application OutOfSync, prompting a sync to reconcile the two states.

Why this answer

In Argo CD, 'OutOfSync' specifically means the live resources in the Kubernetes cluster do not match the manifests stored in the Git repository. Argo CD continuously compares the desired state (from Git) against the live state (from the cluster API) and flags any divergence. It says nothing about the health of Git itself or the cluster's resource capacity — those are separate status dimensions.

Exam trap

The trap here is conflating Argo CD's Sync Status with Health Status or with Git-side errors — candidates pick 'syntax error' or 'API unreachable' because they assume OutOfSync covers any failure, when it strictly means desired-vs-live divergence.

How to eliminate wrong answers

Option B is wrong because a YAML syntax error would surface as a manifest generation or comparison error, not an OutOfSync status — Argo CD would fail to render the manifests entirely. Option C is wrong because an unreachable API server produces a connection/Unknown error state, not OutOfSync; Argo CD cannot even read live state in that case. Option D is wrong because resource exhaustion is a cluster health/runtime concern reported by Kubernetes (e.g., OOMKilled, Pending pods), not by Argo CD's sync comparison logic.

Full explanation →

41

Multi-Selectmedium

Which THREE of the following are primary benefits of adopting GitOps for CI/CD integration?

Select 3 answers

A.Faster code compilation times compared to traditional CI systems.

B.Increased consistency between environments through standardized Git workflows.

C.Reduced need for automated security scanning.

D.Simplified disaster recovery by re-applying the Git state to a new cluster.

E.Improved auditability of changes through Git commit history.

AnswersB, D, E

Git acts as the single source of truth for declarative desired state, so every environment is reconciled from the same versioned manifests. This eliminates configuration drift caused by manual changes, directly delivering the standardised Git workflow consistency the question asks about.

Why this answer

Option B is correct because GitOps uses Git as the single source of truth, so declarative manifests and standardized pull-request workflows ensure every environment is reconciled to the same committed state, eliminating configuration drift. Option D is correct because the entire desired cluster state lives in Git, so disaster recovery becomes a matter of pointing a GitOps operator (e.g., Argo CD or Flux) at the repository and letting it re-apply the manifests to a new cluster. Option E is correct because every change flows through Git commits and pull requests, giving a tamper-evident, attributable history that supports audit and compliance requirements.

Option A is not a GitOps benefit since GitOps concerns deployment and reconciliation, not compiler performance, and Option C is wrong because GitOps does not remove the need for automated security scanning; it typically complements it with policy-as-code and supply-chain checks.

Exam trap

CGOA often tests whether candidates conflate CI concerns (build speed, code scanning) with GitOps CD benefits — the trap is selecting 'faster compilation' or 'less security scanning' as if GitOps changed the CI pipeline itself.

Full explanation →

42

MCQeasy

Which GitOps tool relies primarily on a pull-based model utilizing the 'Source Controller' and 'Kustomization' custom resources?

A.Flux

B.ArgoCD

C.Terraform

D.Helm

AnswerA

Flux uses the Source Controller to fetch manifests from Git repositories and the Kustomization custom resource to reconcile and apply them, implementing a pull-based GitOps model. Argo CD instead relies on Application resources and its own repo-server component.

Why this answer

Flux is a GitOps tool that uses a pull-based model where the Source Controller and Kustomization custom resources are core components. The Source Controller fetches manifests from Git repositories, and Kustomization resources define how to apply those manifests to the cluster. This architecture enables continuous reconciliation of the desired state from Git.

Exam trap

CGOA often tests the distinction between pull-based and push-based GitOps tools, and candidates may confuse Flux's Source Controller and Kustomization with ArgoCD's Application CRD or assume Terraform/Helm provide native GitOps reconciliation.

How to eliminate wrong answers

Option B is wrong because ArgoCD uses a different architecture with its own Application and AppProject custom resources, not Source Controller or Kustomization. Option C is wrong because Terraform is an infrastructure-as-code tool that typically uses a push-based model and does not rely on Kubernetes custom resources for GitOps. Option D is wrong because Helm is a package manager for Kubernetes that templates and deploys applications but does not provide a GitOps pull-based reconciliation loop with Source Controller and Kustomization resources.

Full explanation →

43

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.

Full explanation →

44

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.

Full explanation →

45

MCQhard

What is the impact of having multiple GitOps operators in the same cluster?

A.It is the recommended setup for high availability

B.It leads to potential race conditions and configuration conflicts

C.It automatically distributes the load across nodes

D.It increases the throughput of deployments

AnswerB

Each operator continuously reconciles the same resources toward its own declared state, so overlapping ownership produces write races: one reverts what the other applies. Without clearly partitioned scopes, the cluster oscillates between competing desired states and configuration drifts unpredictably.

Why this answer

Running multiple GitOps operators (e.g., two Argo CD instances or Argo CD plus Flux) against the same cluster means each operator independently reconciles resources toward its own declared desired state. When both manage overlapping resources, they will continuously overwrite each other's changes, producing race conditions, flapping resource states, and configuration conflicts. GitOps assumes a single source of truth per resource, so multiple controllers violate that model rather than improving it.

Exam trap

CGOA often tests the misconception that more operators equals more resilience or throughput, when in reality GitOps requires a single authoritative reconciler per resource to avoid split-brain drift.

How to eliminate wrong answers

Option A is wrong because high availability in GitOps is achieved by running multiple replicas of a single operator (e.g., Argo CD HA with Redis HA and multiple repo-server/application-controller replicas), not by deploying independent operators that fight over the same resources. Option C is wrong because GitOps operators do not load-balance work across nodes; they are control-plane reconcilers, and Kubernetes scheduling—not the operator count—determines pod placement. Option D is wrong because adding operators does not increase deployment throughput; it causes contention and repeated reconciliation loops that can actually slow convergence and trigger API server throttling.

Full explanation →

46

Multi-Selecthard

Which TWO of the following are common challenges when implementing GitOps in an organization?

Select 2 answers

A.Addressing configuration drift caused by manual changes to the cluster.

B.Managing secrets in a secure way within the version control system.

C.The requirement to use only open-source software.

D.The speed at which Git servers process pull requests.

E.The lack of support for containerization in the organization.

AnswersA, B

Manual kubectl edits bypass Git, so the operator's reconciliation reverts them or fights the change, producing drift. Detecting and preventing this drift is a recognised GitOps adoption challenge, directly matching the stem's configuration drift caused by manual cluster changes.

Why this answer

Option A is correct because GitOps relies on Git as the single source of truth, so any manual kubectl edits or out-of-band changes create configuration drift that the reconciliation loop must detect and revert, which is a well-known operational challenge. Option B is correct because storing secrets in plaintext in Git repositories is insecure; teams must adopt solutions such as Sealed Secrets, SOPS, External Secrets Operator, or HashiCorp Vault to keep credentials encrypted and out of the version history. Option C is incorrect because GitOps does not mandate open-source-only tooling; commercial and proprietary platforms can implement the same declarative pull-based model.

Option D is incorrect because Git server pull-request throughput is not a typical GitOps adoption challenge; the bottleneck is usually reconciliation and drift management, not PR processing speed. Option E is incorrect because GitOps is inherently tied to containerized, Kubernetes-style declarative workloads, so a lack of containerization support would be a prerequisite issue rather than a common implementation challenge.

Exam trap

CGOA often tests whether candidates confuse GitOps prerequisites (containerization, Git) with actual challenges (drift, secrets), so picking options about open-source mandates or Git server speed reflects a misunderstanding of GitOps fundamentals.

Full explanation →

47

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.

Full explanation →

48

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.

Full explanation →

49

MCQhard

In an Argo CD 'Application' manifest, what does the 'destination' field specify?

A.The Kubernetes cluster and namespace for deployment

B.The source Git repository URL

C.The build server address

D.The email address for alerts

AnswerA

The destination field names the target cluster by server URL or name plus the namespace, so Argo CD knows where to apply manifests. It satisfies the requirement of directing deployment to a specific cluster and namespace, separate from the source repository definition.

Why this answer

In an Argo CD Application manifest, the destination field defines where the application's manifests will be deployed — specifically the target Kubernetes cluster (by server URL or name) and the target namespace. It is paired with the source field, which points to the Git repository and path containing the desired manifests. Together, source + destination describe the 'what' and the 'where' of the GitOps deployment.

Exam trap

CGOA often tests whether candidates confuse the 'source' and 'destination' fields in an Application manifest — the trap is picking the Git repo URL as the destination because both are central to the manifest.

How to eliminate wrong answers

Option B is wrong because the source Git repository URL is defined in the 'source' field (repoURL), not 'destination'. Option C is wrong because Argo CD does not reference a build server in the Application spec — building images is a CI concern, not a deployment destination. Option D is wrong because alert/notification configuration is handled via Argo CD Notifications (subscriptions, triggers, templates), not the destination field.

Full explanation →

50

MCQhard

When using a GitOps operator that performs 'image polling', what is the risk of using a 'latest' tag?

A.It causes high latency in the cluster.

B.The GitOps operator cannot detect changes.

C.It consumes too much disk space.

D.It makes rollbacks impossible because the 'latest' image may be different than what was deployed.

AnswerD

A 'latest' tag is mutable, so the registry pointer can move to a new digest between deployments. GitOps records only the tag, not the digest, meaning a rollback re-pulls whatever 'latest' currently resolves to rather than the previously running image, so the prior state cannot be reliably restored.

Why this answer

Using a 'latest' tag with a GitOps operator that performs image polling is risky because the tag is mutable — the image it points to can change without any change to the Git manifest. If a rollback is needed, the operator cannot guarantee that the 'latest' image it pulls is the same one that was previously deployed, making rollbacks unreliable and non-deterministic. This breaks the GitOps principle of immutable, versioned desired state.

Exam trap

CGOA often tests the misconception that 'latest' is a version, when in fact it is a mutable tag — the trap is that candidates think the operator cannot detect changes, but the real risk is non-reproducible rollbacks due to the tag's mutability.

How to eliminate wrong answers

Option A is wrong because using a 'latest' tag does not inherently cause high latency in the cluster — latency issues are unrelated to image tagging strategy. Option B is wrong because the GitOps operator can detect changes if it polls the registry and sees a new image digest for the 'latest' tag; the problem is not detection but reproducibility and rollback safety. Option C is wrong because disk space consumption is not a consequence of using 'latest' — image size is determined by the image content, not the tag.

Full explanation →

51

MCQmedium

Which Argo CD feature allows you to manage multiple applications with shared configuration?

A.ApplicationSets.

B.Sync Waves.

C.Application Projects.

D.Resource Hooks.

AnswerA

ApplicationSets use generators to template and deploy many Argo CD Applications from one shared definition, so common configuration such as repository, sync policy and destination is defined once. This is the feature purpose-built for managing multiple applications with shared configuration across clusters.

Why this answer

ApplicationSets is the Argo CD controller that generates multiple Application resources from a single template combined with generators (List, Cluster, Git, Matrix, Merge, Pull Request). It is purpose-built for managing many applications that share configuration, such as one app per cluster or per tenant.

Exam trap

The trap is mixing up ApplicationSets (fan-out generation of Applications) with AppProjects (tenancy/policy) and Sync Waves (ordering), since all three appear in multi-app discussions.

How to eliminate wrong answers

Option B is wrong because Sync Waves control the ordering of resource application within a single sync (using the argocd.argoproj.io/sync-wave annotation), not the generation of multiple applications. Option C is wrong because AppProjects are tenancy and policy boundaries that restrict source repos and destinations, not a templating mechanism for shared config. Option D is wrong because Resource Hooks are lifecycle jobs (PreSync, Sync, PostSync, SyncFail) that run around a sync, not a way to fan out applications.

Full explanation →

52

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.

Full explanation →

53

Multi-Selectmedium

You are auditing your GitOps deployment strategy. Which TWO of the following statements correctly describe the 'Source of Truth' in a GitOps architecture?

Select 2 answers

A.The live cluster state is the ultimate source of truth for all configurations

B.The declared state in the Git repo must match the observed cluster state

C.The Git repository acts as the single source of truth for both infrastructure and applications

D.Database backups constitute the primary source of truth

E.Continuous Integration artifacts are the source of truth

AnswersB, C

Git holds the declared state, and the reconciliation controller continuously compares it against the observed cluster state, driving convergence. This satisfies the stem's requirement that the two states must match, since drift triggers automatic correction rather than manual intervention.

Why this answer

Option B is correct because GitOps relies on continuous reconciliation: the declared state stored in Git must be kept in sync with the observed state of the live cluster, and any drift is detected and corrected by a controller such as Argo CD or Flux. Option C is correct because in GitOps the Git repository is the single source of truth for both infrastructure and application manifests, serving as the authoritative declarative specification from which all deployments are derived. Option A is incorrect because the live cluster state is the observed state, not the source of truth; it is compared against Git and reconciled to match it.

Option D is incorrect because database backups are for data recovery and are unrelated to the declarative configuration source of truth in GitOps. Option E is incorrect because CI artifacts (build outputs, images) are produced by pipelines and are not the authoritative declarative source; Git holds the desired state that references such artifacts.

Exam trap

CGOA often tests the direction of truth in GitOps — the trap is selecting the live cluster as the source of truth, which is the opposite of the GitOps model.

Full explanation →

54

MCQmedium

Your platform team runs a GitOps operator that continuously reconciles a Kubernetes cluster against a Git repository. A compliance auditor asks how you can prove that no unapproved manual changes have been applied to production over the last 90 days. Which practice should you implement to satisfy this requirement?

A.Require every engineer to sign a written attestation each quarter confirming they made no manual production changes.

B.Restrict kubectl access by issuing read-only kubeconfig files to all developers and operators.

C.Increase the GitOps operator's reconciliation interval from five minutes to thirty seconds so changes are corrected faster.

D.Enable drift detection and reconciliation alerts so any divergence between Git and the live cluster is recorded and surfaced.

AnswerD

Drift detection continuously compares the desired state in Git with the live cluster and flags any divergence, including manual kubectl edits. Routing those events to an audit log or alerting system produces a verifiable record of unapproved changes, letting the auditor see when drift occurred, what resource was affected, and whether reconciliation corrected it.

Why this answer

Proving that no unapproved change reached production requires an observational control that compares Git's declared state with the live cluster and records divergences. Drift detection plus reconciliation alerting generates exactly that evidence: timestamps, affected resources, and correction events. Preventive controls like access restriction or faster reconciliation are valuable but do not by themselves produce the retrospective proof the auditor requested.

Exam trap

The trap here is assuming that preventing manual changes with RBAC or faster reconciliation is equivalent to proving none occurred, when audit evidence requires recorded drift events.

Full explanation →

55

MCQmedium

You are running Argo CD on a Kubernetes cluster. A developer reports that the argocd-application-controller repeatedly logs 'Failed to load target state: rpc error: code = Unknown desc = comparison error' for one Application, and the Application is stuck in the 'Unknown' health state. The cluster's outbound internet access is blocked, and the Application sources manifests from a private Git repository over HTTPS. Which component of Argo CD must you check first to resolve this?

A.The argocd-application-controller, because it performs the actual Kubernetes API calls to apply resources and cannot connect to the API server.

B.The argocd-server, because it serves the web UI and API and must fetch the manifests on behalf of the controller.

C.The argocd-repo-server, because it is responsible for cloning the Git repository and generating the manifests, and it cannot reach the private repository.

D.The argocd-dex-server, because it provides authentication and the Application may be failing due to an expired token.

AnswerC

The argocd-repo-server is the component that clones Git repositories and renders manifests. When outbound internet is blocked and the private Git repository is unreachable, reconciliation fails with a comparison error. Checking repo-server logs and network connectivity from its pod is the correct first step to resolve this scenario.

Why this answer

The error indicates Argo CD cannot load the desired manifests from Git. The argocd-repo-server is the component that clones repositories and generates manifests, so blocked outbound access to the private Git repository will cause exactly this failure. Inspecting repo-server logs and connectivity is the correct troubleshooting step.

Exam trap

The trap here is assuming the application-controller handles Git access, when in fact the repo-server is the component that clones and renders manifests.

Full explanation →

56

Multi-Selectmedium

Which TWO of the following are valid ways to configure an Argo CD 'Application'?

Select 2 answers

A.By modifying the Argo CD binary code

B.By writing a shell script that bypasses the API server

C.By applying a YAML manifest via kubectl

D.By using the Argo CD CLI

E.By deleting the Git repository

AnswersC, D

An Argo CD Application is a Kubernetes custom resource, so writing its YAML manifest and applying it with kubectl creates the Application declaratively. This is a valid configuration method alongside the web UI and CLI.

Why this answer

Option C is correct because an Argo CD Application is a Kubernetes custom resource (CRD) of kind Application in the argoproj.io API group, so it can be created or updated declaratively by applying a YAML manifest with kubectl (e.g., kubectl apply -f application.yaml). Option D is correct because the Argo CD CLI provides commands such as 'argocd app create' and 'argocd app set' that configure an Application through the Argo CD API server. Option A is incorrect because modifying the Argo CD binary is neither a supported nor a practical configuration method and would not define an Application resource.

Option B is incorrect because bypassing the API server is not a valid configuration path; Argo CD Applications are managed through the Kubernetes API or Argo CD API. Option E is incorrect because deleting the Git repository removes the source of manifests and does not configure an Application.

Exam trap

CGOA often tests the misconception that Argo CD can be configured through ad-hoc scripts or binary tweaks, when in reality every valid configuration path must ultimately write an Application CRD through the Kubernetes API server — either via kubectl or the Argo CD CLI.

Full explanation →

57

MCQmedium

You have a large ArgoCD installation and want to limit the blast radius. Which feature allows you to restrict which namespaces an application can deploy to?

A.ClusterRoleBinding

B.Sync policies

C.AppProject

D.ApplicationSet

AnswerC

AppProject defines a destination allow-list, restricting an Application to specific clusters and namespaces. This directly satisfies the blast-radius constraint by preventing a compromised or misconfigured Application from deploying outside its permitted namespaces, unlike a global project or RBAC alone.

Why this answer

AppProject is the ArgoCD custom resource that defines a logical grouping of applications with explicit boundaries: permitted source repositories, permitted destination clusters, and permitted destination namespaces. By setting spec.destinations with a namespace allow-list (or wildcard restrictions), the AppProject enforces that any Application assigned to it can only deploy into those namespaces, directly limiting blast radius. This is the documented mechanism for multi-tenant isolation in ArgoCD.

Exam trap

CGOA often tests the confusion between Kubernetes RBAC objects (ClusterRoleBinding) and ArgoCD's own tenancy boundary (AppProject), so candidates who reach for native K8s access control pick the wrong answer.

How to eliminate wrong answers

Option A is wrong because a ClusterRoleBinding is a native Kubernetes RBAC object that grants cluster-wide permissions to a subject; it controls who can perform API actions, not which namespaces an ArgoCD Application may target. Option B is wrong because sync policies (automated sync, self-heal, prune) govern when and how ArgoCD reconciles desired state, not where it is allowed to deploy. Option D is wrong because ApplicationSet is a controller/template that generates multiple Applications from generators; it has no built-in namespace restriction and relies on an AppProject to enforce destination limits.

Full explanation →

58

MCQmedium

In a multi-cluster GitOps architecture using Argo CD, how do you manage credentials for a remote cluster that is not the cluster where Argo CD resides?

A.Modify the global ConfigMap in the Argo CD namespace

B.Add the cluster URL to the Git repository manifest

C.Use the argocd cluster add command to store credentials as a secret in the Argo CD namespace

D.Manually create a Kubernetes secret in the remote cluster

AnswerC

The argocd cluster add command registers the remote cluster with Argo CD and writes its credentials as a Secret in the Argo CD namespace, which is exactly where the controller reads them when deploying to that external cluster.

Why this answer

The 'argocd cluster add' command is the standard way to register an external cluster with Argo CD. It creates a ServiceAccount in the target cluster, generates a kubeconfig, and stores the credentials as a Secret in the Argo CD namespace, allowing Argo CD to manage the remote cluster.

Exam trap

CGOA often tests the specific command for adding clusters, and candidates might think manual Secret creation in the remote cluster is sufficient, overlooking that Argo CD needs the credentials stored locally.

How to eliminate wrong answers

Option A is wrong because modifying a ConfigMap does not handle cluster credentials; Argo CD uses Secrets for sensitive data. Option B is wrong because adding the cluster URL to a Git manifest does not provide authentication credentials. Option D is wrong because manually creating a Secret in the remote cluster does not give Argo CD the necessary access; the credentials must be stored in the Argo CD cluster.

Full explanation →

59

MCQeasy

What is the main advantage of using a 'Declarative' approach to system management?

A.It requires less storage in Git.

B.It allows you to skip CI/CD testing.

C.You can use imperative commands like 'kubectl run'.

D.It makes system state predictable and reproducible.

AnswerD

Declarative management defines the desired end state rather than imperative steps, so the tooling converges the system to that specification regardless of starting conditions. This satisfies the stem's advantage: identical declarations yield predictable, reproducible state across environments and repeated runs.

Why this answer

A declarative approach describes the desired end state of the system, and the tooling continuously reconciles the actual state to match it. This makes the system state predictable and reproducible, because the same declaration applied to any environment yields the same result, and drift can be detected and corrected automatically.

Exam trap

CGOA often tests the contrast between declarative and imperative management — the trap is picking an option that sounds like a benefit (less storage, skip testing) but is either false or unrelated to the declarative paradigm.

How to eliminate wrong answers

Option A is wrong because declarative manifests are not inherently smaller in Git — they can be larger than imperative scripts, and storage is not the advantage. Option B is wrong because declarative management does not remove the need for CI/CD testing; in fact, testing is essential to validate the declared state. Option C is wrong because imperative commands like kubectl run are the opposite of the declarative approach — they issue direct actions rather than declaring desired state.

Full explanation →

60

MCQhard

A company transitions from a push-based CI/CD pipeline (using Jenkins) to a pull-based GitOps model (using Flux). What is the primary security architectural change regarding cluster access?

A.Git is no longer the source of truth

B.The cluster no longer requires an API server

C.The operator is now a push-based agent

D.The CI server no longer requires cluster credentials

AnswerD

In a pull-based GitOps model, the in-cluster operator (Flux) pulls manifests from Git and reconciles them itself, so the external CI server never authenticates to the cluster. Removing those stored cluster credentials eliminates a standing privileged access path that Jenkins previously held.

Why this answer

In a pull-based GitOps model, the in-cluster operator (Flux) pulls desired state from Git and applies it from inside the cluster. The CI server's only job is to build and push artifacts and commit manifest changes to Git — it never needs kubeconfig or cluster API credentials. This removes the long-lived cluster credentials that a push-based Jenkins pipeline required to run kubectl/helm against the cluster.

Exam trap

CGOA often tests the misconception that GitOps still requires CI to hold cluster credentials, when the whole point of pull-based GitOps is that credentials never leave the cluster.

How to eliminate wrong answers

Option A is wrong because Git remains the single source of truth in GitOps — that is the defining principle, not something that changes. Option B is wrong because the Kubernetes API server is still required; the operator uses it to apply and reconcile resources, only the direction of initiation changes. Option C is wrong because the operator is pull-based, not push-based — it watches Git and pulls changes rather than receiving pushes from CI.

Full explanation →

61

MCQhard

When a manual change is made directly to a Kubernetes Service via 'kubectl edit', what behavior is expected from a properly configured GitOps operator set to 'Automatic Sync'?

A.The operator identifies the drift and automatically overwrites the live state with the Git version.

B.The operator ignores the change to prevent production downtime.

C.The operator updates the Git repository to match the new manual change.

D.The operator prompts the administrator for manual approval before reverting.

AnswerA

With Automatic Sync enabled, the operator's reconciliation loop detects the live Service diverging from the Git-declared manifest and immediately reapplies the desired state, overwriting the manual edit. This self-healing behaviour enforces Git as the single source of truth, satisfying the constraint that drift must be corrected without human intervention.

Why this answer

With Automatic Sync enabled, a GitOps operator such as Argo CD continuously compares live cluster state against the desired state in Git. When it detects drift — for example, a manual kubectl edit to a Service — it automatically re-applies the Git version, overwriting the manual change. This self-healing behaviour is the core guarantee of GitOps: Git remains the single source of truth.

Exam trap

CGOA often tests whether candidates understand that Automatic Sync overwrites live drift rather than updating Git, catching those who confuse the operator's read-only relationship with Git.

How to eliminate wrong answers

Option B is wrong because ignoring drift defeats the purpose of GitOps; operators are designed to detect and correct drift, not tolerate it. Option C is wrong because GitOps operators never write back to Git — Git is the authoritative source, and the operator only reads from it (unless a separate tool like Argo CD Image Updater is configured to commit changes). Option D is wrong because manual approval is the behaviour of Manual Sync mode, not Automatic Sync; Automatic Sync reconciles without human intervention.

Full explanation →

62

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.

Full explanation →

63

Multi-Selectmedium

Which TWO of the following are valid ways to trigger a sync in ArgoCD?

Select 2 answers

A.Sending a kill signal to the controller

B.Clicking 'Sync' in the ArgoCD UI

C.Webhook from Git repository

D.Deleting the Git repository

E.Restarting the API server

AnswersB, C

Clicking 'Sync' in the ArgoCD UI triggers a manual sync by submitting a sync request to the application controller, which then reconciles the live cluster state against the desired manifests in Git. This satisfies the stem's requirement for a valid trigger method, as the UI provides a direct, supported mechanism for initiating synchronisation.

Why this answer

Option B is correct because the ArgoCD web UI provides a 'Sync' button on each Application that triggers an immediate synchronization of the desired manifests from Git to the target cluster. Option C is correct because ArgoCD supports Git webhooks (e.g., GitHub, GitLab, Bitbucket) that notify the argocd-server when a repository changes, allowing automated sync to be triggered without manual intervention. Option A is incorrect because sending a kill signal to the controller would terminate the process rather than initiate a sync, and ArgoCD does not interpret OS signals as sync triggers.

Option D is incorrect because deleting the Git repository removes the source of truth and would cause sync failures, not trigger a sync. Option E is incorrect because restarting the API server only restarts the ArgoCD API component; it does not itself initiate an application sync.

Exam trap

CGOA often tests the difference between reconciliation (the polling loop) and sync (applying desired state), causing candidates to pick operational actions like restarting components as if they were sync triggers.

Full explanation →

64

MCQhard

You are using a 'Pull' based GitOps model (e.g., Flux or Argo CD). Why is it considered more secure than a 'Push' based CI/CD model?

A.It allows faster deployment times.

B.It does not require a container registry.

C.It is easier to configure with SSH keys.

D.It eliminates the need for cluster credentials on the CI server.

AnswerD

In a pull model the in-cluster agent (Flux or Argo CD) initiates outbound connections to fetch desired state, so the CI server never holds kubeconfig or cluster credentials. This removes the high-value attack target that a push pipeline's stored credentials represent.

Why this answer

In a Pull-based GitOps model, the agent (Flux or Argo CD) runs inside the target cluster and pulls the desired state from Git. The CI system never needs kubeconfig credentials or cluster-admin tokens to push manifests, so a compromise of the CI pipeline cannot be used to directly mutate the cluster. This removes the most dangerous credential exposure path in traditional push-based pipelines.

Exam trap

CGOA often tests the misconception that pull-based GitOps is 'more secure' because of encryption or authentication features, when the real reason is credential isolation — the CI server never holds cluster credentials.

How to eliminate wrong answers

Option A is wrong because deployment speed is not the security differentiator — pull and push models can both be fast, and speed is irrelevant to the threat model. Option B is wrong because both pull and push models still require a container registry to host images; the registry is orthogonal to the GitOps sync mechanism. Option C is wrong because SSH key configuration is not inherently easier in pull mode — pull agents typically use HTTPS tokens or deploy keys, and SSH ease-of-use is not a security property.

Full explanation →

65

Multi-Selectmedium

Which THREE of the following are common methods for managing secrets in a GitOps workflow?

Select 3 answers

A.External Secrets Operator

B.Sealed Secrets

C.Mozilla SOPS

D.Committing raw Kubernetes Secret YAMLs

E.Hardcoding credentials in Dockerfiles

AnswersA, B, C

External Secrets Operator reconciles Kubernetes Secret objects from an external vault or cloud secret manager, so no plaintext credential ever enters Git. This satisfies the GitOps workflow by keeping the repository declarative while secrets stay in a dedicated store.

Why this answer

The External Secrets Operator (A) is correct because it syncs secrets from external secret managers (e.g., AWS Secrets Manager, HashiCorp Vault) into Kubernetes Secrets, keeping the source of truth outside Git while still enabling GitOps reconciliation. Sealed Secrets (B) is correct because it uses asymmetric encryption so that encrypted SealedSecret resources can be safely committed to Git and decrypted only by the controller in the cluster. Mozilla SOPS (C) is correct because it encrypts values within YAML/JSON files using KMS, age, or PGP keys, allowing encrypted secret manifests to be stored in Git and decrypted during the GitOps pipeline.

Committing raw Kubernetes Secret YAMLs (D) is not acceptable because base64 encoding is not encryption, so credentials would be exposed in the repository. Hardcoding credentials in Dockerfiles (E) is not acceptable because it bakes plaintext secrets into image layers, exposing them to anyone with image access and violating secret-management best practices.

Exam trap

CGOA often tests whether candidates recognize that base64 encoding is not encryption — the trap is selecting 'committing raw Secret YAMLs' as acceptable because it looks like standard Kubernetes practice.

Full explanation →

66

MCQmedium

A platform team runs a GitOps operator that continuously reconciles cluster state from a Git repository. A compliance auditor asks how the team can prove which commit produced the configuration currently running in production six weeks ago, after many merges and rollbacks. Which practice best satisfies this requirement?

A.Tag every commit that reaches production and require the operator to record the reconciled commit SHA as an annotation on each managed resource.

B.Store the operator's reconciliation logs in a central log platform with a twelve-month retention policy.

C.Require all changes to production to be applied manually with kubectl after a four-eyes review in the change advisory board.

D.Enable drift detection alerts so any divergence between Git and the cluster is reported to the team's chat channel.

AnswerA

Recording the reconciled commit SHA as an annotation on managed resources creates a durable, queryable link between live objects and the exact Git revision that generated them. Combined with immutable tags, an auditor can later inspect the running resource, read the annotation, and trace it back to the commit, its author, and its review history. This directly answers the provenance question for any point in time.

Why this answer

Provenance in GitOps comes from making the link between live state and the Git revision explicit and durable. Annotating each reconciled resource with the commit SHA it was rendered from, together with immutable tags, lets anyone inspect a running object and trace it to the exact commit, author, and review. Monitoring alerts, manual application, and log retention support operations but do not answer which commit produced the current configuration.

Exam trap

The trap here is assuming that observability tooling such as drift alerts or retained reconciliation logs constitutes an audit trail of which commit is running.

Full explanation →

67

MCQmedium

A platform team runs Argo CD against a Git repository that holds Helm charts for a production cluster. During an incident, an SRE patches a Deployment directly with `kubectl set image` to roll back a bad release. Two minutes later the Deployment is back on the bad image. Which GitOps concept explains why the manual patch did not persist?

A.Continuous reconciliation, because the agent continuously converges live state toward the declared desired state in Git.

B.Git as the single source of truth, because Kubernetes refuses API writes that were not committed to the repository.

C.Progressive delivery, because the agent automatically reverts any change that fails a health gate.

D.Immutable infrastructure, because Kubernetes replaces any container whose image differs from the manifest.

AnswerA

Continuous reconciliation means the GitOps agent repeatedly compares live cluster state with the desired state stored in Git and re-applies the declared configuration whenever they diverge. The SRE's imperative patch created a divergence, so the next sync cycle restored the Git-declared image, which is exactly the behavior observed. This is the defining operational characteristic of GitOps rather than a one-time deployment event.

Why this answer

The agent's repeated comparison of live state against the Git-declared desired state is what undid the manual patch. GitOps operators run a control loop that detects divergence and reapplies the repository content, so imperative changes are transient by design. The other concepts describe rollout strategy, infrastructure replacement, or governance policy, none of which actively rewrites a mutated Deployment object.

Exam trap

The trap here is assuming Kubernetes itself rejects manual edits, when in fact the GitOps agent's periodic resynchronization is what overwrites the out-of-band change.

Full explanation →

68

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.

Full explanation →

69

MCQmedium

You are implementing progressive delivery with Flagger. You notice that the canary analysis is failing despite the new version being stable. What is the most common reason for this?

A.The deployment strategy is set to 'Immediate' instead of 'Canary'.

B.The Prometheus query for success rate is returning no data.

C.The Git repository is in read-only mode.

D.The service mesh sidecar is missing the 'canary' annotation.

AnswerB

Flagger's canary analysis depends on Prometheus metrics; if the success-rate query returns no data, Flagger treats the metric as failed and aborts the rollout. The stable version is fine, but the query itself is misconfigured or the metric name is wrong.

Why this answer

The most common reason for canary analysis failure in Flagger despite a stable new version is that the Prometheus query for success rate returns no data. Flagger relies on metrics from Prometheus to evaluate canary health; if the query is misconfigured or returns empty, Flagger interprets this as failure and rolls back. This is a frequent configuration issue.

Exam trap

CGOA often tests the dependency of Flagger on Prometheus metrics — candidates may overlook that missing metrics data causes analysis failure, not the stability of the new version.

How to eliminate wrong answers

Option A is wrong because if the deployment strategy were 'Immediate', Flagger would not perform canary analysis at all; the question states canary analysis is failing, implying it is configured. Option C is wrong because Git repository read-only mode would prevent updates but not cause canary analysis failure; Flagger would not even start. Option D is wrong because a missing 'canary' annotation on the sidecar is not a standard requirement; Flagger uses its own custom resources and annotations on the deployment, not the sidecar.

Full explanation →

70

MCQhard

You are using Flux and want to pause reconciliation for a specific application without deleting the resource. Which field should you modify?

A.interval: 0

B.reconcile: false

C.suspend: true

D.pause: true

AnswerC

Setting `suspend: true` in the Flux Kustomization or HelmRelease spec halts reconciliation entirely, satisfying the requirement to pause a specific application without deleting it. The controller stops applying manifests while retaining the resource and its state, so reconciliation resumes simply by reverting the field to false.

Why this answer

Flux CRDs such as GitRepository, Kustomization, and HelmRelease expose a 'suspend' boolean field. Setting spec.suspend: true tells the controller to stop reconciling that object without deleting it, so the last-applied state remains in the cluster. Removing the field (or setting it to false) resumes reconciliation.

Exam trap

CGOA often tests the confusion between Flux and ArgoCD field names — candidates pick 'pause' (ArgoCD terminology) instead of Flux's 'suspend', or invent a 'reconcile: false' field that does not exist.

How to eliminate wrong answers

Option A is wrong because interval: 0 is not a valid pause mechanism — Flux expects a duration string like '1m' or '5m', and a zero interval would either be rejected by validation or cause undefined behavior, not a clean pause. Option B is wrong because 'reconcile' is not a recognized field in Flux CRDs; there is no boolean to disable reconciliation under that name. Option D is wrong because 'pause' is not a Flux field — that naming is used by ArgoCD (spec.syncPolicy or the argocd app pause command), not Flux, so candidates confuse the two tools.

Full explanation →

71

MCQmedium

You are using ArgoCD and need to ensure that secret values stored in Git via Sealed Secrets are decrypted only within the target cluster. What component performs the actual decryption of a SealedSecret resource?

A.GitOps CLI (kubeseal)

B.Kubernetes API Server

C.ArgoCD Application controller

D.Sealed Secrets controller

AnswerD

The Sealed Secrets controller runs inside the target cluster, holds the private key, and decrypts SealedSecret resources into ordinary Secrets. This satisfies the constraint that decryption happens only within the target cluster, since the private key never leaves it and Git stores only ciphertext.

Why this answer

The Sealed Secrets controller is the in-cluster component (deployed as a Kubernetes controller/operator) that holds the private key used to decrypt SealedSecret resources. When a SealedSecret CRD is applied, the controller watches for it, decrypts the encrypted payload using the cluster's private key, and creates a standard Kubernetes Secret that workloads can consume. This design ensures the asymmetric private key never leaves the target cluster, so Git only ever stores ciphertext.

Exam trap

The trap here is confusing the client-side encryption tool (kubeseal) with the in-cluster decryption controller — candidates often assume the CLI or ArgoCD performs decryption because they see the SealedSecret being applied.

How to eliminate wrong answers

Option A is wrong because kubeseal is a client-side CLI used to encrypt plaintext secrets into SealedSecret manifests using the cluster's public key — it performs encryption, not decryption, and runs outside the cluster. Option B is wrong because the Kubernetes API Server only stores and serves the SealedSecret CRD object; it has no knowledge of the sealed-secrets private key and performs no cryptographic decryption of the payload. Option C is wrong because the ArgoCD Application controller only syncs manifests from Git to the cluster — it applies the SealedSecret resource but delegates decryption entirely to the Sealed Secrets controller.

Full explanation →

72

MCQhard

You are debugging a drift in a GitOps environment. The cluster state differs from the Git repository. What is the most likely cause if you are using Flux?

A.The container registry is unreachable during a new image rollout.

B.The Git repository contains syntax errors in the YAML files.

C.A user performed a manual 'kubectl' command to modify a deployment.

D.The CI pipeline failed to run tests.

AnswerC

Flux continuously reconciles the cluster toward Git, so divergence arises from an out-of-band change rather than Git itself. A manual kubectl edit mutates the live object directly, which the controller then detects as drift against the committed manifest.

Why this answer

Flux continuously reconciles the cluster state with the desired state defined in Git. If a user manually modifies a resource with kubectl, that change is not in Git, so Flux will detect the drift and may revert it. This is the most likely cause of drift in a GitOps environment because Git is the single source of truth.

Other options would typically cause deployment failures or prevent updates, but not drift between Git and the cluster.

Exam trap

CGOA often tests the misconception that any failure in the CI/CD pipeline or external dependencies causes drift, but drift specifically refers to unauthorized or out-of-band changes to the cluster state, not failures in the deployment process.

How to eliminate wrong answers

Option A is wrong because an unreachable container registry would prevent new pods from starting during an image rollout, but it does not cause the cluster state to differ from Git; the desired state in Git remains unchanged and Flux would still attempt to apply it. Option B is wrong because syntax errors in YAML would cause Flux to fail applying the manifests, resulting in no change to the cluster rather than a drift; the cluster would remain at the last successfully applied state. Option D is wrong because a CI pipeline failure is unrelated to the runtime state of the cluster; CI pipelines typically build and test code, not directly modify the cluster, so they do not cause drift between Git and the cluster.

Full explanation →

73

MCQmedium

How do you handle 'Environment-specific' configurations in a GitOps repository?

A.By creating separate branches for each environment

B.By having multiple Git repositories per cluster

C.By using overlays or templating tools

D.By hardcoding the environment in the application

AnswerC

Overlays and templating tools such as Kustomize and Helm let a single manifest base be patched per environment, so dev, staging and production values diverge without duplicating YAML. This satisfies the environment-specific configuration constraint while keeping everything declarative and version-controlled in Git.

Why this answer

Environment-specific configurations in GitOps are best handled with overlays or templating tools such as Kustomize overlays or Helm values files. These allow a single base configuration to be customized per environment (dev, staging, prod) without duplicating manifests, keeping the repository DRY and maintainable while preserving a single source of truth.

Exam trap

CGOA often tests the misconception that separate branches per environment are a clean way to isolate environments, when in reality they break the single-source-of-truth model and cause drift.

How to eliminate wrong answers

Option A is wrong because using separate branches per environment breaks the GitOps principle of a single source of truth and leads to merge conflicts, drift, and difficulty promoting changes between environments. Option B is wrong because multiple Git repositories per cluster fragments configuration, complicates access control, and makes cross-environment consistency harder to enforce. Option D is wrong because hardcoding environment values in the application violates the twelve-factor app methodology and makes promotion between environments require code changes rather than configuration changes.

Full explanation →

74

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.

Full explanation →

75

MCQmedium

You are configuring an Argo CD application. After a developer manually modifies a Kubernetes Service via kubectl, the application status changes to 'OutOfSync'. Which GitOps principle is this monitoring process specifically identifying?

A.Drift detection

B.Rollback recovery

C.Image promotion

D.Webhook integration

AnswerA

Drift detection compares live cluster state against the desired state declared in Git. The manual kubectl edit diverged from Git, so Argo CD flagged the Service as OutOfSync, precisely identifying configuration drift rather than a sync failure or health degradation.

Why this answer

When a developer edits a Service directly with kubectl, the live state diverges from the desired state in Git, and Argo CD flags the Application as OutOfSync. This is precisely drift detection: the continuous comparison between the cluster's actual state and the Git-declared state. Argo CD's application-controller polls or watches resources and computes a diff, surfacing any divergence as OutOfSync until reconciled.

Exam trap

The trap here is confusing drift detection (detecting divergence) with self-healing (correcting divergence)—the question asks which principle is being identified, not remediated.

How to eliminate wrong answers

Option B is wrong because rollback recovery refers to reverting to a previous known-good Git commit or sync revision, not detecting that the live cluster has diverged. Option C is wrong because image promotion is the CI/CD practice of moving a tested image tag through environments (e.g., dev→staging→prod), which is unrelated to detecting manual kubectl edits. Option D is wrong because webhook integration is a notification/triggering mechanism (e.g., GitHub webhooks to trigger syncs), not the principle that identifies divergence between live and desired state.

Full explanation →

Page 1 of 5

All pages

Practice CGOA by domain

Target a specific domain to shore up weak areas.

Tooling Gitops Terminology Related Practices Gitops Patterns Gitops Principles

See all domains with question counts →