Knowledge + Practice

CCNA Gitops Terminology Questions

70 questions · Gitops Terminology topic · All types, answers revealed

Practice these questions Exam hub All questions

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.

Practice this question →

2

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.

Practice this question →

3

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.

Practice this question →

4

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.

Practice this question →

5

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.

Practice this question →

6

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.

Practice this question →

7

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.

Practice this question →

8

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.

Practice this question →

9

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.

Practice this question →

10

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.

Practice this question →

11

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.

Practice this question →

12

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.

Practice this question →

13

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.

Practice this question →

14

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.

Practice this question →

15

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.

Practice this question →

16

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.

Practice this question →

17

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.

Practice this question →

18

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.

Practice this question →

19

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.

Practice this question →

20

MCQeasy

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

A.Jenkins

B.Flux

C.Ansible

D.Terraform

AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

21

MCQeasy

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

A.To store the database backups for the application.

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

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

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

AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

22

MCQmedium

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

A.The operator waits for a manual override

B.The operator deletes the application

C.The cluster crashes

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

AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

23

MCQmedium

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

A.It requires public IP addresses

B.It requires maintaining an operator within the cluster

C.It is slower than pushing

D.It creates a security hole

AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

24

Multi-Selecthard

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

Select 3 answers

A.Unexpected changes to resource labels or annotations

B.Manual editing of a ConfigMap via kubectl

C.Successful CI pipeline execution

D.Unauthorized scaling of a deployment

E.Git commit history being too long

AnswersA, B, D

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

Why this answer

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

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

Exam trap

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

Practice this question →

25

MCQhard

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

A.Running unit tests on application code

B.Generating new Kubernetes manifests

C.Managing user authentication for the Git provider

D.Continuously ensuring the cluster state matches the Git repository

AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

26

Multi-Selecteasy

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

Select 2 answers

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

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

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

D.Automating the deployment process using a GitOps operator.

E.Storing application manifests in a central repository.

AnswersA, C

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

Why this answer

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

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

Exam trap

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

Practice this question →

27

MCQmedium

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

A.To watch the repository and reconcile the cluster state

B.To host the container registry

C.To generate user tokens

D.To manage Git branches

AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

28

Multi-Selectmedium

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

Select 2 answers

A.Clear audit trail of who changed what and when

B.Automated rollback via git revert

C.Automatic removal of unused cloud accounts

D.Increased reliance on manual terminal access

E.Faster CPU performance for applications

AnswersA, B

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

Why this answer

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

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

Exam trap

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

Practice this question →

29

Multi-Selecthard

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

Select 3 answers

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

B.External Load Balancer

C.Git Repository (Source of Truth)

D.Manual Deployment Script

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

AnswersA, C, E

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

Why this answer

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

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

Exam trap

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

Practice this question →

30

Multi-Selectmedium

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

Select 2 answers

A.It is a purely external monitoring tool

B.It generates application source code

C.It runs inside the Kubernetes cluster

D.It requires manual triggers for every update

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

AnswersC, E

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

Why this answer

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

Exam trap

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

Practice this question →

31

MCQmedium

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

A.The operator wipes the current state

B.The cluster reverts to a hardcoded default

C.The cluster automatically deletes all applications

D.The operator waits and retries the fetch

AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

32

MCQeasy

Which term best describes the process of ensuring the live cluster matches the desired state stored in Git?

A.Validation

B.Syncing

C.Provisioning

D.Compilation

AnswerB

Syncing is the reconciliation loop in which the GitOps operator continuously compares the live cluster state against the desired state declared in Git and applies changes to close any drift, ensuring the cluster converges on the committed configuration.

Why this answer

Syncing is the GitOps term for the process of applying the desired state from Git to the live cluster so that the actual state matches the declared state. In Argo CD, a sync operation applies manifests; in Flux, reconciliation achieves the same. The question describes exactly this convergence process, making 'Syncing' the correct term.

Exam trap

CGOA often tests terminology precision—candidates may confuse syncing (applying desired state) with validation (checking manifests) or compilation (rendering templates), so the exact definition matters.

How to eliminate wrong answers

Option A is wrong because validation refers to checking that manifests are well-formed and pass schema/policy checks (e.g., kubeval, OPA), not to applying them to the cluster. Option C is wrong because provisioning is the broader act of creating infrastructure or resources (e.g., Terraform provisioning), not the GitOps-specific convergence of live state to Git state. Option D is wrong because compilation refers to rendering templates (Helm, Kustomize, Jsonnet) into plain YAML, which happens before syncing, not the act of matching live to desired state.

Practice this question →

33

Multi-Selecthard

Which THREE of the following are common tasks performed by a GitOps Operator? (Choose three)

Select 3 answers

A.Applying configurations to the cluster to resolve detected drift.

B.Generating unit tests for Kubernetes manifests.

C.Comparing the current cluster state with the state defined in Git.

D.Building and pushing new Docker images to a registry.

E.Continuous monitoring of the Git repository for new commits.

AnswersA, C, E

Applying configurations to resolve detected drift is the controller's core remediation action: once it observes that live resources deviate from the Git-declared desired state, it writes those manifests back onto the cluster, restoring convergence. This satisfies the operator task of enforcing the declared state continuously.

Why this answer

Option A is correct because a GitOps Operator continuously reconciles the cluster by applying the desired configuration from Git whenever it detects drift between the live state and the declared state. Option C is correct because the operator's core reconciliation loop compares the actual cluster state against the desired state stored in Git to determine whether any action is needed. Option E is correct because the operator continuously monitors the Git repository (e.g., via polling or webhooks) for new commits so it can pull and apply updated manifests.

Option B is not a GitOps Operator task, since unit testing of manifests is a CI/development activity rather than runtime reconciliation. Option D is also not a GitOps Operator task, because building and pushing container images belongs to a CI pipeline (e.g., Jenkins, GitHub Actions), not to the operator that syncs cluster state.

Exam trap

CGOA often tests the boundary between CI responsibilities (building, testing) and GitOps operator responsibilities (monitoring, comparing, applying) — candidates incorrectly assign CI tasks to the operator.

Practice this question →

34

MCQhard

A financial services firm deploys Argo CD to manage three production clusters. Auditors ask how the firm can prove that no unauthorized change reached production in the last quarter. Which GitOps property most directly satisfies this audit requirement?

A.An immutable, signed Git history records every approved desired-state change, and reconciliation makes the cluster match that history.

B.The Argo CD UI maintains a dashboard showing the sync status of every application across all clusters.

C.Role-based access control on each cluster restricts kubectl access to a small group of senior engineers.

D.Kubernetes audit logs capture every API request made to each cluster's control plane.

AnswerA

Git provides a cryptographically verifiable, append-only record of who changed what and when, and signed commits or tags strengthen that guarantee. Because the GitOps agent only applies what is committed, the repository history becomes an authoritative audit trail of every intended production change. Auditors can therefore correlate cluster state with reviewed and merged commits rather than relying on ad hoc operator logs.

Why this answer

Git's immutable, reviewable, and optionally signed commit history gives auditors a verifiable record of every intended production change, and reconciliation ensures the cluster reflects exactly that history. Dashboards are transient, Kubernetes audit logs are short-lived and lack approval context, and RBAC is preventive rather than evidentiary. Together, versioned history plus automated convergence provides the provenance auditors require.

Exam trap

The trap here is treating operational dashboards or cluster audit logs as sufficient audit evidence, when only the versioned Git history ties each change to a review and approval.

Practice this question →

35

MCQmedium

You are troubleshooting a Flux installation. The operator is failing to pull updates from a private GitHub repository. What component is most likely misconfigured?

A.The Helm chart version

B.The cluster service account permissions

C.The Kustomization path

D.The GitRepository secret

AnswerD

The GitRepository custom resource references a Kubernetes secret holding the credentials or SSH key used to authenticate to the private repository. If that secret is missing, malformed, or lacks valid credentials, the operator cannot pull updates, producing exactly the described failure.

Why this answer

Flux uses a GitRepository custom resource to define the source repository, including the URL, branch, and authentication secret. If the operator cannot pull updates from a private GitHub repository, the most likely misconfiguration is the GitRepository secret — the credentials (e.g., SSH key or token) referenced by the GitRepository are incorrect, missing, or lack permissions.

Exam trap

The trap is focusing on downstream deployment artifacts (Helm chart, Kustomization path) when the failure is at the source-fetch stage, where authentication secrets are the usual culprit.

How to eliminate wrong answers

Option A is wrong because the Helm chart version affects which chart version is deployed, not whether Flux can authenticate to and pull from the Git repository. Option B is wrong because cluster service account permissions govern what the deployed workloads can do in the cluster, not Flux's ability to fetch from Git. Option C is wrong because the Kustomization path defines which directory within the repository to apply, but if the repository cannot be pulled at all, the path is irrelevant.

Practice this question →

36

MCQmedium

What does the 'prune' setting in a GitOps controller do?

A.Removes unused Git branches

B.Automatically deletes resources from the cluster that are no longer in Git

C.Trims logs to save disk space

D.Limits the number of replicas

AnswerB

Pruning enforces the Git repository as the single source of truth: any resource present in the cluster but absent from the desired manifests is deleted. This directly satisfies the declarative reconciliation model, preventing orphaned objects from lingering after they are removed from Git.

Why this answer

The prune setting in a GitOps controller instructs it to delete live cluster resources that are no longer declared in Git. When enabled, if a manifest is removed from the repository, the controller will remove the corresponding object from the cluster during the next sync, keeping the cluster an exact mirror of Git. Without pruning, deleted manifests leave orphaned resources running indefinitely, causing drift and resource leakage.

Exam trap

CGOA often tests whether candidates confuse prune with Git-side cleanup or log management, so the trap is selecting an option that describes repository or logging maintenance rather than cluster resource deletion.

How to eliminate wrong answers

Option A is wrong because removing unused Git branches is a Git repository housekeeping task, not something a GitOps controller does — the controller reads from Git, it does not manage branches. Option C is wrong because trimming logs to save disk space is a log rotation or retention concern handled by logging agents or Kubernetes log rotation, not by the prune setting. Option D is wrong because limiting the number of replicas is controlled by the replicas field in a Deployment or by a Horizontal Pod Autoscaler, not by the prune setting.

Practice this question →

37

Multi-Selectmedium

Which TWO of the following are common GitOps terminology used to describe the state of an application?

Select 2 answers

A.Temporary State

B.Desired State

C.Live State

D.Future State

E.Legacy State

AnswersB, C

Desired state is the target configuration declared in Git, expressing how the application and its resources should look. The GitOps engine continuously reconciles the cluster toward this declared state, making it one of the two canonical terms describing application state alongside live state.

Why this answer

In GitOps, the Desired State (B) is the declarative configuration stored in Git that defines how the application and its infrastructure should look, serving as the single source of truth that the GitOps operator continuously reconciles toward. The Live State (C), also called the observed or actual state, is the real-time condition of the running application and cluster as reported by the GitOps agent (e.g., Argo CD or Flux), which is compared against the desired state to detect drift. These two terms form the core reconciliation loop of GitOps: the controller drives the live state to match the desired state.

The other options are not GitOps terminology: Temporary State (A), Future State (D), and Legacy State (E) are not standard terms used to describe application state in GitOps workflows.

Exam trap

CGOA often tests whether candidates recognise the canonical GitOps state terminology, so the trap is selecting plausible-sounding but non-standard terms like 'Future State' or 'Temporary State' instead of the correct 'Desired State' and 'Live State'.

Practice this question →

38

MCQeasy

What is the primary benefit of version controlling your cluster manifests?

A.It allows you to host files on your local desktop

B.It replaces the need for a database

C.It allows you to track, audit, and revert cluster changes

D.It speeds up node startup time

AnswerC

Git history records every manifest change with author and timestamp, so you can audit who altered the cluster and roll back to any prior commit. This directly satisfies the requirement to track, audit, and revert changes, unlike imperative kubectl edits that leave no declarative record.

Why this answer

Version controlling cluster manifests (e.g., YAML files for Kubernetes resources) provides a historical record of every change made to the desired state of the cluster. This enables tracking who changed what and when, auditing for compliance or troubleshooting, and reverting to a previous working state if a change causes issues. These capabilities are core to GitOps and infrastructure-as-code practices, where the manifest repository is the single source of truth for cluster configuration.

Exam trap

CGOA often tests the misconception that version control is primarily for backup or local file storage, rather than for tracking, auditing, and reverting changes in a collaborative environment.

How to eliminate wrong answers

Option A is wrong because version control systems like Git are designed for distributed collaboration and remote repositories, not for hosting files on a local desktop; local hosting is incidental and not the primary benefit. Option B is wrong because version control does not replace databases; it stores files and their history, but databases are still needed for structured data storage, querying, and transactional integrity. Option D is wrong because version controlling manifests has no direct impact on node startup time; node startup depends on the container runtime, kubelet configuration, and image pull times, not on whether manifests are stored in Git.

Practice this question →

39

MCQeasy

What does 'Declarative Configuration' imply in GitOps?

A.The system is defined by files that describe the desired final state

B.Only developers can access the system

C.The database is the source of truth

D.You must manually type every command

AnswerA

Declarative configuration stores the intended end state in files rather than imperative commands, so the tooling continuously works to make reality match that written specification. This satisfies the GitOps requirement that Git holds the single source of truth describing the desired final state.

Why this answer

Declarative configuration means you write files (YAML manifests, Helm charts, Kustomize overlays) that describe the desired end state of the system, and a controller continuously reconciles actual state to match. You declare 'what' the system should look like, not 'how' to get there step by step. This is the foundation of GitOps because the declarative files can be version-controlled and diffed.

Exam trap

CGOA often tests the confusion between declarative ('what') and imperative ('how') — candidates pick answers about manual commands or databases, missing that declarative means files describing desired end state.

How to eliminate wrong answers

Option B is wrong because access control is an RBAC/security concern unrelated to whether configuration is declarative or imperative — declarative systems can have any permission model. Option C is wrong because in GitOps the Git repository (not a database) is the source of truth; databases may store runtime state but are not the declarative source. Option D is wrong because manually typing commands is the definition of imperative configuration, the exact opposite of declarative — declarative systems apply files, not ad-hoc commands.

Practice this question →

40

MCQeasy

What does the status 'Healthy' mean in an Argo CD application?

A.The network is secure

B.The database is fully backed up

C.The application is running as expected in the cluster

D.The Git repository is updated

AnswerC

Argo CD marks an application Healthy when its live Kubernetes resources match the desired manifests in Git and all workloads, such as Deployments and StatefulSets, report ready replicas. This reflects the stem's expectation of the application running as expected in the cluster.

Why this answer

In Argo CD, the 'Healthy' status is a health assessment of the live Kubernetes resources that make up an application. It means that all resources are in a healthy state according to their health checks—for example, Deployments have all replicas available, Pods are Running and Ready, and Services have endpoints. This indicates the application is running as expected in the cluster, not merely that Git is synced or that infrastructure components like network or database backups are in place.

Exam trap

CGOA often tests the confusion between 'Healthy' and 'Synced' statuses, tricking candidates into selecting an answer about Git repository updates when the question asks about health.

How to eliminate wrong answers

Option A is wrong because 'Healthy' does not refer to network security; Argo CD health checks do not evaluate TLS, firewall rules, or other security configurations. Option B is wrong because database backups are outside the scope of Argo CD's health assessment; Argo CD monitors Kubernetes resource states, not backup jobs. Option D is wrong because Git repository update status is related to the 'Synced' condition, not 'Healthy'; an application can be Synced but not Healthy, or vice versa.

Practice this question →

41

MCQeasy

In a GitOps environment using Argo CD, what is the primary purpose of the reconciliation loop?

A.To automatically apply changes from the Git repository to the target Kubernetes cluster.

B.To perform unit testing on manifest files before they are merged.

C.To push new container images to the registry whenever a build completes.

D.To scale deployment replicas based on real-time traffic metrics.

AnswerA

Argo CD continuously compares the desired state stored in Git against the live cluster state and, on detecting drift, syncs the cluster to match Git. This automatic convergence is what satisfies the requirement to apply Git changes to the target Kubernetes cluster without manual intervention.

Why this answer

Argo CD's reconciliation loop continuously compares the desired state in Git with the live state in the cluster and, when auto-sync is enabled, applies the differences to bring the cluster into the desired state. This is the core mechanism that makes Git the source of truth for deployments.

Exam trap

CGOA often tests whether candidates confuse Argo CD's reconciliation (applying Git state to cluster) with CI tasks like testing, image pushing, or autoscaling — the trap is selecting a CI or HPA responsibility as the reconciliation loop's purpose.

How to eliminate wrong answers

Option B is wrong because unit testing of manifests is performed by CI pipelines (e.g., kubeval, conftest, helm template) before merge, not by Argo CD's reconciliation loop. Option C is wrong because pushing container images to a registry is a CI/build responsibility, not Argo CD's — Argo CD deploys manifests that reference images. Option D is wrong because scaling based on traffic metrics is the job of the Horizontal Pod Autoscaler (HPA) or KEDA, not Argo CD's reconciliation loop.

Practice this question →

42

MCQmedium

A team uses Flux to manage a cluster. They want the cluster to automatically apply new commits to a configuration repository without any external pipeline pushing to the cluster. Which Flux component and behavior accomplish this?

A.The source-controller watches the Git repository and produces an artifact that the kustomize-controller reconciles into the cluster.

B.The notification-controller receives webhooks from the Git host and applies the changed manifests itself.

C.The helm-controller polls the Git repository directly and renders charts during each reconciliation cycle.

D.The image-reflector-controller scans the container registry and commits updated tags back to the configuration repository.

AnswerA

In Flux, the source-controller is responsible for fetching Git, OCI, Helm, and bucket sources and exposing them as artifacts, while the kustomize-controller applies the Kustomization resources built from those artifacts. Together they implement pull-based reconciliation directly inside the cluster. No external CI system needs cluster credentials, which is precisely the security advantage of the pull model the team is seeking.

Why this answer

Flux's pull-based model is implemented by the source-controller fetching repository content and producing artifacts that the kustomize-controller then reconciles into the cluster. This lets in-cluster agents detect and apply new commits without external pipeline credentials. The notification, helm, and image-reflector controllers serve different roles and do not themselves apply the changed manifests from Git.

Exam trap

The trap here is assuming a single Flux controller does everything, when in fact source retrieval and manifest application are deliberately separated across controllers.

Practice this question →

43

MCQeasy

A startup is adopting GitOps for its Kubernetes platform. The CTO asks the platform engineer to describe the defining property of the deployment model they are about to adopt. Which statement best captures the core GitOps principle?

A.Operators package application logic into custom controllers that manage the full lifecycle of their own resources.

B.Every production change requires a change advisory board approval recorded in an external ticketing system before deployment.

C.The desired state of the system is declared in Git, and automated agents continuously converge the running system toward it.

D.Application artifacts are built in CI and pushed to the cluster by the pipeline after every merge to the main branch.

AnswerC

This is the canonical definition of GitOps: a declarative description of the intended system state is version-controlled in Git, and software agents continuously reconcile the live environment with that description. It combines declarative configuration, versioned source of truth, and automated convergence, which together distinguish GitOps from scripted or ticket-driven deployment approaches.

Why this answer

GitOps is defined by declarative desired state stored in Git plus automated agents that continuously reconcile the running system to match it. Push-based pipelines, ticketing gates, and operator patterns are related but not the defining property. The convergence loop and the versioned declarative source are what make the model auditable, reproducible, and self-healing.

Exam trap

The trap here is confusing GitOps with ordinary CI/CD automation, where a pipeline pushes changes rather than an agent pulling and reconciling declared state.

Practice this question →

44

MCQmedium

What happens when a resource's 'SyncPolicy' is set to 'Manual'?

A.The operator will delete the resource

B.The operator will stop watching the repository

C.The operator will report 'OutOfSync' until a human triggers the sync

D.The operator will automatically sync as soon as a change is detected

AnswerC

Manual sync policy disables automatic reconciliation, so Argo CD continuously reports OutOfSync whenever live state diverges from Git. A human must trigger the sync, satisfying the requirement that no automated deployment occurs without explicit approval.

Why this answer

When SyncPolicy is set to Manual, the GitOps operator still watches the repository and computes the diff between desired and live state, but it does not apply changes automatically. As soon as a difference is detected, the application is marked OutOfSync, and it remains in that state until a human explicitly triggers a sync (e.g., via the UI, CLI, or API). This gives operators control over when changes hit the cluster, which is useful for production environments requiring approval gates.

Exam trap

CGOA often tests the difference between Manual and Automated sync policies, and candidates frequently confuse 'Manual' with 'the operator stops watching' — the key is that watching and reporting continue, only the apply step is gated.

How to eliminate wrong answers

Option A is wrong because a Manual sync policy does not cause the operator to delete resources — deletion would only occur if the manifest removed the resource and a sync was triggered, or if pruning was enabled and a sync occurred. Option B is wrong because the operator continues to watch the repository and report sync status; it simply does not auto-apply, so stopping the watch would defeat the purpose of drift detection. Option D is wrong because automatic syncing upon change detection is the definition of Automated Sync, not Manual — Manual explicitly requires human intervention.

Practice this question →

45

MCQmedium

Your team wants to implement GitOps. Which of the following is a critical prerequisite for 'Drift Detection' to be effective?

A.The cluster must have an external load balancer exposed to the internet.

B.The operator must have read access to the Git repository and the cluster's current live state.

C.Developers must manually commit to Git every time a pod restarts.

D.The Git repository must contain the running container images themselves.

AnswerB

Drift detection compares desired state in Git against actual live state in the cluster, so the operator needs read access to both. Without reading the repository manifests and the running resources, no meaningful comparison is possible, satisfying the prerequisite for detecting divergence.

Why this answer

Drift detection in GitOps works by continuously comparing the desired state stored in Git with the actual live state of the cluster. To perform this comparison, the GitOps operator (e.g., Argo CD, Flux) must be able to read both the Git repository (to fetch the desired manifests) and the cluster's live resources (to observe the current state). Without read access to both, the operator cannot detect any divergence, making drift detection impossible.

Exam trap

CGOA often tests the misconception that GitOps requires write access or that drift detection involves manual intervention, when in fact it relies on read access to both Git and the cluster for continuous comparison.

How to eliminate wrong answers

Option A is wrong because an external load balancer is not required for drift detection; the operator only needs network access to the Git repository and the Kubernetes API server, which can be internal. Option C is wrong because drift detection is automatic and continuous; manual commits on pod restarts would be impractical and defeat the purpose of GitOps. Option D is wrong because Git repositories store manifests and configuration, not container images; images are stored in container registries and referenced by URL in the manifests.

Practice this question →

46

MCQmedium

A platform team manages a Kubernetes cluster with Flux. They want to ensure that if the cluster's live state diverges from the Git repository, the system automatically corrects it without human intervention. Which GitOps concept does this describe?

A.Immutable Infrastructure

B.Continuous Delivery

C.Reconciliation

D.Declarative Configuration

AnswerC

Reconciliation is the GitOps mechanism where an operator continuously compares the desired state in Git with the actual state in the cluster and applies changes to eliminate any drift. In this scenario, Flux's reconciliation loop would detect the divergence and automatically correct it, fulfilling the team's requirement for self-healing without manual intervention.

Why this answer

Reconciliation is the continuous process by which a GitOps operator like Flux or Argo CD compares the desired state stored in Git with the actual state of the cluster and automatically applies any necessary changes to eliminate drift. This self-healing behavior is exactly what the platform team requires to maintain consistency without manual intervention.

Exam trap

The trap here is confusing reconciliation with declarative configuration, assuming that simply declaring the desired state in Git is enough to guarantee the cluster stays in sync.

Practice this question →

47

MCQeasy

What is the primary function of an 'Operator' in the context of GitOps?

A.Automating the reconciliation process within the cluster

B.Hosting the Git repository

C.Writing application code

D.Executing SQL queries

AnswerA

An operator runs a control loop inside the cluster that continuously compares desired state from Git with live state, then applies or corrects drift. This reconciliation is its primary function, distinguishing it from one-off CI pipelines that push changes without ongoing convergence.

Why this answer

In GitOps, an Operator is a Kubernetes controller that extends the API with custom resources and continuously reconciles the cluster to match the declared desired state. It encodes operational knowledge — such as how to deploy, upgrade, back up, or failover an application — into software that runs inside the cluster. This automation of the reconciliation process is precisely what makes Operators central to GitOps workflows.

Exam trap

CGOA often tests whether candidates conflate the Operator with the Git server or with CI tooling, so the trap is choosing an option that describes infrastructure hosting or code authoring rather than in-cluster reconciliation automation.

How to eliminate wrong answers

Option B is wrong because hosting the Git repository is the job of a Git server such as GitHub, GitLab, or Bitbucket — an Operator runs inside Kubernetes and does not provide Git hosting. Option C is wrong because writing application code is a human developer activity; Operators automate operational tasks, not source code authoring. Option D is wrong because executing SQL queries is a database-specific action that an Operator might trigger as part of managing a database, but it is not the primary function of an Operator in GitOps — the primary function is reconciliation.

Practice this question →

48

MCQhard

What is the difference between a 'Sync' and a 'Refresh' in Argo CD?

A.Refresh updates the application status; Sync applies changes to the cluster

B.Sync is for reading; Refresh is for writing

C.Refresh is for Git; Sync is for the cloud provider API

D.They are the same thing

AnswerA

Refresh re-reads the desired manifests from Git and the live state from the cluster, updating only Argo CD's status and diff without touching workloads. Sync then reconciles the cluster to match Git, applying the manifests. This satisfies the stem's distinction: status observation versus actual cluster mutation.

Why this answer

In Argo CD, 'Refresh' is a read-only operation that re-queries the Git repository and the live cluster to update the application's status, diff, and sync state without modifying anything. 'Sync' is the write operation that applies the desired manifests from Git to the target Kubernetes cluster, bringing live state into alignment with the declared state. The two are distinct phases: Refresh detects drift, Sync remediates it.

Exam trap

CGOA often tests the read-versus-write distinction between Refresh and Sync, and candidates commonly assume both operations mutate the cluster or that Sync is the status-checking action.

How to eliminate wrong answers

Option B is wrong because it reverses the semantics — Sync is the write/apply action, not a read, and Refresh is the read/reconcile-status action, not a write. Option C is wrong because both operations involve Git as the source of truth; Refresh reads Git and the cluster, while Sync writes to the cluster — neither is scoped to 'the cloud provider API' as a separate concern. Option D is wrong because conflating them ignores that Refresh never mutates cluster resources while Sync does, which is the entire basis of Argo CD's safe drift-detection workflow.

Practice this question →

49

MCQhard

How does an operator manage 'Secrets' in a GitOps repository?

A.By disabling secrets entirely

B.By using specialized tools or controllers to decrypt secrets at runtime

C.By storing them as plain text in the repo

D.By hardcoding them in the application code

AnswerB

Plaintext secrets cannot be committed safely, so tools such as Sealed Secrets, SOPS or External Secrets decrypt at runtime inside the cluster. This satisfies the constraint that Git holds only encrypted data while workloads receive usable secrets.

Why this answer

Because Git repositories are not designed to store plaintext secrets securely, GitOps practitioners use specialized tools — such as Sealed Secrets, SOPS, External Secrets Operator, or Vault integrations — to encrypt secrets at rest in Git and decrypt them at runtime inside the cluster. The encrypted blob is committed to the repo, and a controller decrypts it into a native Kubernetes Secret when syncing. This preserves Git as the source of truth without exposing credentials.

Exam trap

CGOA often tests secret management in GitOps; candidates may pick 'store as plaintext' out of convenience or misunderstand that encryption-at-rest in Git plus runtime decryption is the accepted pattern.

How to eliminate wrong answers

Option A is wrong because disabling secrets entirely is not viable — applications require credentials, tokens, and certificates to function, and removing them breaks workloads. Option C is wrong because storing secrets as plaintext in the repo exposes them to anyone with read access, including in commit history, and violates security best practices and compliance requirements. Option D is wrong because hardcoding secrets in application code embeds credentials in container images and source, making rotation and revocation extremely difficult and leaking secrets to anyone who can read the code or image.

Practice this question →

50

MCQhard

You are architecting a multi-cluster deployment. What is the benefit of using an 'Operator' based architecture over a standard CI/CD Push approach in this context?

A.It allows the CI pipeline to run faster by offloading deployment tasks.

B.It removes the need to store sensitive cluster administrative credentials in an external CI/CD tool.

C.It ensures that the Git repository is automatically updated with the latest cluster metrics.

D.It forces developers to use the CLI for all infrastructure changes.

AnswerB

Operators run inside each cluster and reconcile desired state locally, so the external CI/CD pipeline never holds cluster-admin kubeconfig credentials. This removes a high-value secret from the pipeline, satisfying the multi-cluster credential-exposure constraint that a push model cannot avoid.

Why this answer

The correct answer is B because an Operator runs inside the cluster and continuously reconciles desired state from custom resources, so it can authenticate using its own in-cluster ServiceAccount rather than requiring an external CI/CD system to hold cluster-admin kubeconfig or tokens. This inverts the trust model: the CI pipeline only needs to commit manifests or trigger a CR, while the Operator performs privileged actions locally. It also enables pull-based GitOps workflows where the cluster fetches changes instead of an external tool pushing them.

Exam trap

CGOA often tests the misconception that Operators are primarily about CI speed or Git write-back, when the real architectural benefit is removing external privileged credentials through in-cluster reconciliation.

How to eliminate wrong answers

Option A is wrong because Operators do not inherently make CI pipelines faster; they shift reconciliation to the cluster, which can add latency and does not offload build/test work. Option C is wrong because Operators reconcile cluster state toward Git, not write cluster metrics back into Git; metrics collection is handled by monitoring stacks like Prometheus. Option D is wrong because Operators are API-driven and typically managed via kubectl, GitOps controllers, or the Kubernetes API, not by forcing developers to use the CLI for all changes.

Practice this question →

51

Multi-Selectmedium

Which TWO of the following are NOT recommended in a GitOps workflow?

Select 2 answers

A.Automated reconciliation of state

B.Manual changes via kubectl

C.Storing plain-text secrets in the repository

D.Using Git as a source of truth

E.Using pull requests for code changes

AnswersB, C

Manual changes via kubectl bypass Git, the declared source of truth, creating drift that the reconciler later reverts. Such out-of-band edits break the audit trail and reproducibility GitOps depends on, so they are explicitly discouraged in favour of committing changes to the repository.

Why this answer

Option B (Manual changes via kubectl) is NOT recommended in a GitOps workflow because GitOps requires the Git repository to be the single source of truth, and any out-of-band change made directly with kubectl creates configuration drift that the reconciliation controller will detect and revert, defeating the declarative model. Option C (Storing plain-text secrets in the repository) is NOT recommended because committing unencrypted credentials to Git exposes sensitive data to anyone with repository access and to the permanent Git history, violating security best practices; secrets should instead be managed with tools like Sealed Secrets, SOPS, or an external vault. By contrast, option A (Automated reconciliation of state) is a core GitOps principle, typically implemented by controllers such as Argo CD or Flux continuously comparing live cluster state to the desired state in Git.

Option D (Using Git as a source of truth) is the foundational GitOps tenet, providing versioning, auditability, and rollback. Option E (Using pull requests for code changes) is recommended because it enables peer review, CI validation, and an auditable approval trail before changes are merged and deployed.

Exam trap

CGOA often tests whether candidates recognize that manual kubectl changes and plain-text secrets are anti-patterns, while automated reconciliation and Git-as-source-of-truth are core requirements — the trap is selecting recommended practices as 'not recommended.'

Practice this question →

52

Multi-Selecthard

Which THREE of the following are valid ways to trigger a sync in a GitOps environment?

Select 3 answers

A.Pushing a commit to the Git repository

B.Manually clicking 'Sync' in the dashboard

C.Logging into the node via SSH

D.Restarting the Kubernetes API server

E.Sending a webhook notification from the Git provider

AnswersA, B, E

Pushing a commit to the Git repository triggers sync because the GitOps operator continuously reconciles desired state from Git against the cluster. This satisfies the stem's requirement for a valid trigger: any new commit alters the declared configuration, prompting the controller to detect drift and apply the updated manifests automatically.

Why this answer

Option A is correct because in a GitOps model the Git repository is the single source of truth, so pushing a commit changes the desired state and the GitOps controller (e.g., Argo CD or Flux) detects the new revision and reconciles the cluster to match it. Option B is correct because GitOps tools such as Argo CD expose a manual 'Sync' action in their UI/dashboard that forces the controller to apply the current desired manifests immediately, regardless of the automatic polling interval. Option E is correct because Git providers like GitHub, GitLab, or Bitbucket can send webhook notifications to the GitOps controller's endpoint, letting it react instantly to repository events instead of waiting for the next poll cycle.

Option C is not valid because SSH access to a node is an imperative administrative action that does not alter the Git-declared desired state and is not a GitOps sync trigger. Option D is not valid because restarting the Kubernetes API server is an infrastructure operation that does not change or re-read the Git source of truth and is unrelated to triggering reconciliation.

Exam trap

CGOA often tests the misconception that any cluster-level action (SSH, API server restart) can trigger a GitOps sync, when in reality only Git state changes, explicit sync commands, or webhook notifications drive reconciliation.

Practice this question →

53

Multi-Selecthard

Which THREE of the following are core responsibilities of a GitOps operator?

Select 3 answers

A.Detecting drift between the cluster state and the Git source

B.Writing CI/CD build scripts

C.Executing manual kubectl commands for developers

D.Applying necessary changes to reconcile the live state with the desired state

E.Continuously monitor the declared state in the repository

AnswersA, D, E

A GitOps operator compares the desired state declared in Git against the live cluster state, identifying any divergence. Detecting drift is a core responsibility because it is the prerequisite step that triggers reconciliation, satisfying the stem's requirement for an operator responsibility.

Why this answer

Option A is correct because a GitOps operator's fundamental job is to compare the live cluster state against the desired state stored in Git, thereby detecting configuration drift. Option D is correct because once drift is detected, the operator must apply the necessary changes (for example, via server-side apply or kubectl-equivalent reconciliation) to bring the live state back into alignment with the declared state. Option E is correct because the operator must continuously watch or poll the Git repository so that any commit to the desired state is promptly noticed and acted upon, which is the essence of the pull-based GitOps model.

Options B and C are not core responsibilities: writing CI/CD build scripts belongs to the CI pipeline and application teams, not the GitOps operator, and executing manual kubectl commands for developers is an ad-hoc human action that contradicts the automated, declarative reconciliation the operator performs.

Exam trap

CGOA often tests whether candidates attribute CI pipeline duties or manual kubectl execution to the GitOps operator, so the trap is selecting options that describe build-time or imperative activities instead of the declarative reconciliation triad.

Practice this question →

54

MCQhard

In a GitOps environment, what is the role of a 'CI Pipeline'?

A.To replace the GitOps operator

B.To validate changes and commit them to the GitOps repo

C.To execute the reconciliation loop

D.To handle user authentication for the cluster

AnswerB

In GitOps, the CI pipeline builds and tests code, then commits the updated manifests to the GitOps repository. The Git repository remains the single source of truth, and a separate delivery agent reconciles cluster state from it, keeping continuous delivery decoupled from CI.

Why this answer

In GitOps, the CI pipeline's job is to build, test, and validate changes, then commit the resulting manifests (or updated image tags) into the GitOps repository. The GitOps operator (e.g., Argo CD or Flux) then detects the commit and reconciles the cluster to match. CI produces the desired state; the GitOps controller applies it.

Exam trap

CGOA often tests the CI/CD boundary in GitOps — the trap is assuming CI performs the deployment or reconciliation, when in GitOps CI only commits and the operator deploys.

How to eliminate wrong answers

Option A is wrong because the CI pipeline does not replace the GitOps operator — the operator is what continuously reconciles cluster state against Git, a function CI does not perform. Option C is wrong because the reconciliation loop is executed by the GitOps controller (Argo CD's application controller or Flux's kustomize/helm controllers), not by CI. Option D is wrong because cluster user authentication is handled by Kubernetes RBAC, OIDC, or the GitOps tool's own auth layer — not by the CI pipeline.

Practice this question →

55

Multi-Selecthard

Which THREE of the following represent key concepts in 'GitOps'?

Select 3 answers

A.Infrastructure as Code (IaC)

B.Manual intervention for every change

C.Direct terminal access to production

D.Automated Reconciliation

E.Git as the Source of Truth

AnswersA, D, E

Infrastructure as Code underpins GitOps by keeping declarative infrastructure definitions in Git, so every change is versioned, reviewed and auditable. This satisfies the stem's requirement for a key concept, since GitOps depends on IaC to reconcile desired state automatically rather than through manual provisioning.

Why this answer

Option A (Infrastructure as Code) is correct because GitOps requires all infrastructure and application configuration to be expressed declaratively in code, so it can be versioned and stored in Git rather than configured manually. Option D (Automated Reconciliation) is correct because a GitOps agent (e.g., Argo CD or Flux) continuously compares the live cluster state against the desired state in Git and automatically converges the system to that desired state. Option E (Git as the Source of Truth) is correct because in GitOps the Git repository is the single authoritative source for the desired state of the system, and all changes flow through Git commits and pull requests.

Option B (Manual intervention for every change) is not a GitOps concept, since GitOps emphasizes automated, declarative deployments triggered by Git changes rather than manual steps. Option C (Direct terminal access to production) is also not a GitOps concept, as GitOps discourages direct imperative access to production in favor of changes made through Git and applied by the reconciliation controller.

Exam trap

CGOA often tests the misconception that GitOps allows or requires manual cluster intervention — candidates confuse 'Git as source of truth' with 'Git as one of several sources of truth' and pick options implying direct terminal access or manual change approval.

Practice this question →

56

MCQeasy

What does the status 'OutOfSync' indicate in Argo CD?

A.The live resources are not identical to the Git manifests

B.The Git repository is empty

C.The application is running out of memory

D.The Argo CD server is offline

AnswerA

OutOfSync means the live cluster resources differ from the desired state declared in the Git manifests, so Argo CD reports drift between what Git specifies and what actually runs. It does not indicate a healthy or successfully reconciled application.

Why this answer

In Argo CD, the 'OutOfSync' status indicates that the live state of the resources in the Kubernetes cluster does not match the desired state defined in the Git manifests. Argo CD continuously compares the two and flags any drift, allowing operators to detect and reconcile differences. This is a core part of GitOps: Git is the source of truth, and any deviation is considered out of sync.

Exam trap

The trap is confusing sync status with health status — candidates may pick 'running out of memory' (a health issue) or 'server offline' (a connectivity issue) instead of recognizing that 'OutOfSync' specifically refers to a mismatch between Git and the live cluster state.

How to eliminate wrong answers

Option B is wrong because an empty Git repository would result in a different error or status (e.g., 'Unknown' or a sync error), not 'OutOfSync' — OutOfSync specifically means there is a difference between desired and live states, not that the repo is empty. Option C is wrong because 'OutOfSync' is a synchronization status, not a resource health status; running out of memory would be reflected in the application's health status (e.g., 'Degraded' or 'Progressing'), not the sync status. Option D is wrong because if the Argo CD server is offline, the application status would be unknown or unreachable, not 'OutOfSync' — OutOfSync requires Argo CD to be running and actively comparing states.

Practice this question →

57

MCQeasy

If you want to view the history of changes made to your cluster configuration, where should you look in a GitOps model?

A.The cluster event logs

B.The developer's local workstation

C.The cloud provider billing dashboard

D.The Git repository commit history

AnswerD

Git stores every configuration change as an immutable commit, giving a complete, auditable timeline of cluster state. Because GitOps treats the repository as the single source of truth, the commit history is precisely where configuration change history lives, satisfying the requirement to view past modifications.

Why this answer

In a GitOps model, Git is the single source of truth for the desired state of the cluster, so the commit history of the Git repository is the authoritative audit trail of every configuration change. Each commit records who changed what and when, and Argo CD or Flux ties deployed revisions back to specific commits. This is the core GitOps principle: the cluster's change history lives in version control, not in the cluster itself.

Exam trap

CGOA often tests the 'Git as single source of truth' principle; candidates may choose cluster event logs because they think of them as the audit trail, missing that Git commit history is the authoritative change record in GitOps.

How to eliminate wrong answers

Option A is wrong because cluster event logs capture runtime events (pod scheduling, image pulls, probe failures) but not the declarative intent or the human-authored change history — they show effects, not the source-of-truth changes. Option B is wrong because a developer's local workstation is not authoritative; changes only count once committed and pushed to the shared Git repository, and local uncommitted edits are invisible to the GitOps controller. Option C is wrong because the cloud provider billing dashboard tracks spend and resource consumption, not configuration changes or their authorship.

Practice this question →

58

Multi-Selecthard

Which THREE of the following are benefits of using a GitOps operator for CD?

Select 3 answers

A.Automatic creation of development environments

B.Continuous synchronization of desired state

C.Increased visibility into drift

D.Reduced reliance on external CI system credentials

E.Requirement for manual approvals on every sync

AnswersB, C, D

A GitOps operator continuously reconciles live cluster state with the desired state declared in Git, automatically correcting divergence. This delivers ongoing synchronisation without manual intervention, satisfying the benefit of keeping environments perpetually aligned with the repository.

Why this answer

Option B is correct because a GitOps operator such as Argo CD or Flux continuously reconciles the live cluster state against the desired state declared in Git, automatically applying changes when the repository is updated. Option C is correct because the operator continuously compares actual versus desired state and surfaces any drift through its status, health, and diff views, giving teams clear visibility into configuration divergence. Option D is correct because the operator runs inside the cluster and pulls manifests directly from Git, so the external CI system no longer needs long-lived cluster credentials to push deployments, reducing the credential attack surface.

Option A is not a core benefit of a GitOps operator, since environment creation is typically handled by IaC tooling or platform templates rather than the CD reconciler itself. Option E is incorrect because GitOps operators do not require manual approval on every sync; they are designed for automated reconciliation, with manual gates being optional and configurable.

Exam trap

CGOA often tests whether candidates confuse GitOps operator benefits with general CI/CD or IaC capabilities — options like 'automatic environment creation' or 'manual approval on every sync' sound plausible but misattribute the value proposition.

Practice this question →

59

Multi-Selectmedium

Which TWO of the following are primary benefits of adopting a GitOps 'Pull' model compared to a 'Push' model? (Choose two)

Select 2 answers

A.It simplifies the initial setup of CI/CD pipelines.

B.It improves security by removing the need for long-lived cluster credentials in external CI systems.

C.It reduces the total number of containers running in the cluster.

D.It eliminates the need for exposing the Kubernetes API server to external CI/CD tools.

E.It ensures that manual cluster changes are automatically committed to the Git repository.

AnswersB, D

A pull model keeps cluster credentials inside the cluster, so external CI systems no longer hold long-lived kubeconfigs or service account tokens. The GitOps operator reconciles from within, authenticating outbound to Git and the registry instead. This directly satisfies the stem's security benefit by shrinking the credential exposure surface that push-based pipelines create.

Why this answer

Option B is correct because in a GitOps Pull model an in-cluster agent (e.g., Argo CD or Flux) reconciles the desired state from Git, so external CI systems no longer need long-lived cluster credentials such as kubeconfig files or service account tokens to push changes into the cluster. Option D is correct because the same in-cluster agent initiates outbound connections to Git and the cluster API stays internal, so the Kubernetes API server does not need to be exposed to external CI/CD tools, shrinking the attack surface. The unmarked options do not belong: A is false because Pull-based GitOps typically adds components (the reconciler/agent) and can make initial setup more involved, not simpler; C is false because GitOps does not inherently reduce the number of containers running in the cluster and usually adds the agent's own pods; and E is false because GitOps reconciles Git to the cluster, not the reverse, so manual cluster changes are reverted rather than automatically committed back to Git.

Exam trap

CGOA often tests the misconception that pull-based GitOps simplifies setup or reduces containers — the real benefit is security via credential isolation and no inbound API exposure, and candidates must distinguish benefits from unrelated claims.

Practice this question →

60

MCQmedium

When a GitOps tool reports a 'Sync Error', what is the most likely cause?

A.The Git repository is deleted

B.The cluster has too many nodes

C.The manifest contains invalid Kubernetes syntax

D.The network latency is high

AnswerC

A Sync Error means the tool fetched the manifests but failed to apply them, and malformed YAML or invalid Kubernetes schema is rejected by the API server at that stage. Valid syntax would instead produce OutOfSync or Synced states.

Why this answer

A 'Sync Error' in a GitOps tool such as Argo CD or Flux means the operator successfully retrieved the desired state from Git but failed to apply it to the cluster. The most common root cause is that the manifest itself is invalid — malformed YAML, an unknown API version, a missing required field, or a schema violation that the Kubernetes API server rejects. Because the error surfaces during the apply/reconcile step rather than the fetch step, it points squarely at the manifest content rather than connectivity or infrastructure capacity.

Exam trap

CGOA often tests the distinction between a Sync Error (apply-phase failure caused by bad manifests) and repository/connectivity errors (fetch-phase failures), so candidates who pick 'repository deleted' or 'high latency' confuse the fetch stage with the apply stage.

How to eliminate wrong answers

Option A is wrong because a deleted Git repository would produce a repository access or authentication failure (e.g., 'repository not found' or 'authentication required'), not a Sync Error, since the operator would never reach the apply phase. Option B is wrong because having too many cluster nodes is a capacity/scaling concern that does not cause sync failures — Kubernetes schedules workloads across nodes transparently and node count is not part of the desired-state comparison. Option D is wrong because high network latency would manifest as slow reconciliation, timeouts, or 'Unknown' health states, not a deterministic Sync Error, and transient latency typically self-heals on the next reconcile loop.

Practice this question →

61

MCQhard

In a GitOps workflow, how does an operator handle a situation where a user manually deletes a resource that is defined in Git?

A.It creates an alert and waits for manual intervention

B.It updates the Git repository to reflect the deletion

C.It automatically recreates the resource

D.It blocks all future deployments until a reset occurs

AnswerC

The GitOps operator continuously reconciles live cluster state against the desired state declared in Git. When a resource is manually deleted, the observed state diverges, so the reconciliation loop detects the drift and reapplies the manifest, automatically recreating the resource without human intervention.

Why this answer

A GitOps operator continuously reconciles live cluster state against the desired state declared in Git. If a resource defined in Git is manually deleted, the operator detects the drift during its next reconciliation cycle and recreates the resource to match Git. Git remains the authoritative source, so the deletion is treated as unauthorized drift to be corrected.

Exam trap

The trap is confusing GitOps self-healing with alerting tools — candidates may pick 'alert and wait' because they conflate drift detection with manual remediation, but GitOps operators auto-recreate by design.

How to eliminate wrong answers

Option A is wrong because GitOps operators do not wait for manual intervention — they self-heal automatically by default. Option B is wrong because the operator never writes back to Git; Git is the source of truth and manual cluster changes are not propagated upstream. Option D is wrong because a single drift event does not block future deployments — the operator simply reconciles the missing resource and continues normal operation.

Practice this question →

62

MCQeasy

Which of the following is considered 'best practice' for GitOps repository structure?

A.Storing source code and manifest files in the same directory

B.Keeping all configuration in a single root file

C.Using a separate repository for environment configurations

D.Committing binary files to the repo

AnswerC

Environment-specific values, such as replica counts and ingress hosts, diverge per cluster; isolating each environment in its own repository prevents a change for staging from being promoted accidentally to production, and lets teams scope access controls per environment.

Why this answer

Best practice for GitOps repository structure is to separate application source code from deployment configuration, and often to use separate repositories (or at least separate directories) for environment-specific configurations (dev, staging, prod). This separation enables independent promotion, access control, and rollback per environment, and prevents a change to one environment from inadvertently affecting another. Using a separate repository for environment configurations is a recognized best practice.

Exam trap

CGOA often tests the misconception that co-locating code and manifests or using a single monolithic config file is simpler and therefore better, when best practice emphasizes separation for promotion, RBAC, and blast-radius control.

How to eliminate wrong answers

Option A is wrong because storing source code and manifest files in the same directory couples application code changes with deployment changes, making it harder to promote artifacts independently and increasing the risk of unintended deployments. Option B is wrong because keeping all configuration in a single root file creates a monolithic, hard-to-maintain structure that lacks modularity, makes environment-specific overrides difficult, and increases blast radius of changes. Option D is wrong because committing binary files to the repo bloats the repository, breaks diffability, and violates GitOps principles of declarative, text-based, reviewable configuration.

Practice this question →

63

MCQmedium

You are comparing GitOps deployment models. Which scenario best describes a 'Pull' deployment model?

A.A webhook triggers a Jenkins job to build and deploy an application.

B.A developer runs a helm upgrade command from their local machine to the cluster.

C.A Jenkins CI pipeline executes kubectl apply commands against the production cluster.

D.A Flux controller monitors the Git repository and updates the cluster state internally.

AnswerD

In a pull model, an in-cluster agent such as Flux watches the Git repository and reconciles the cluster itself, rather than an external pipeline pushing changes in. The controller initiating updates internally defines the pull pattern.

Why this answer

A Pull-based GitOps model is characterised by an in-cluster agent (such as Flux or Argo CD) that continuously monitors the Git repository and pulls the desired state into the cluster, reconciling any differences itself. The Flux controller watching Git and updating cluster state internally is the textbook example of this pattern. The cluster initiates the connection, which improves security because no external system needs cluster credentials.

Exam trap

CGOA often tests the direction of the deployment flow — candidates confuse Push (external CI applies to cluster) with Pull (in-cluster agent fetches from Git), so watch for who initiates the connection.

How to eliminate wrong answers

Option A is wrong because a webhook-triggered Jenkins job is a Push model — an external CI system pushes changes into the cluster rather than an in-cluster agent pulling them. Option B is wrong because a developer running helm upgrade locally is a manual Push operation with no GitOps reconciliation loop at all. Option C is wrong because a Jenkins pipeline executing kubectl apply against production is again a Push model, where the CI system holds cluster credentials and drives deployment from outside.

Practice this question →

64

MCQeasy

In GitOps, what should happen if a configuration file is deleted from the Git repository?

A.The operator alerts the admin and stops

B.The cluster keeps the resource forever

C.The operator ignores the change

D.The operator deletes the resource from the cluster

AnswerD

GitOps reconciliation is bidirectional: the operator continuously compares live cluster state against Git, which is the single source of truth. Deleting the manifest from Git makes the resource absent from the desired state, so the operator prunes it from the cluster to restore convergence.

Why this answer

In GitOps, Git is the single source of truth for desired state. If a manifest is deleted from Git, the desired state no longer includes that resource, so the operator's reconciliation loop will delete the corresponding resource from the cluster to converge live state with Git. This is the declarative, self-healing behaviour that makes GitOps predictable.

Exam trap

The trap is assuming the operator treats Git deletions as errors or ignores them — candidates must recognize that GitOps is declarative and bidirectional in effect: removing from Git removes from the cluster (when pruning is enabled).

How to eliminate wrong answers

Option A is wrong because the operator does not stop and alert on deletion — it treats the deletion as an intentional desired-state change and acts on it (unless the resource is protected by a sync policy or finalizer). Option B is wrong because keeping the resource forever would violate the source-of-truth principle and create permanent drift. Option C is wrong because ignoring the change would mean Git is no longer authoritative, defeating the entire GitOps model.

Practice this question →

65

MCQhard

What is the purpose of 'App-of-Apps' pattern in Argo CD?

A.To perform parallel builds

B.To increase the memory capacity of the cluster

C.To manage a collection of applications via a single root application

D.To allow multiple users to edit the same file

AnswerC

The App-of-Apps pattern uses one root Argo CD Application that points to a directory of child Application manifests, so a single sync creates and manages them all. This hierarchical management satisfies the stem's requirement for managing a collection of applications.

Why this answer

The App-of-Apps pattern in Argo CD uses a single root Application whose manifests define multiple child Applications. Syncing the root application creates or updates all the child applications, enabling centralised management of a large collection of applications. This hierarchical approach simplifies bootstrapping and governance across many services or clusters.

Exam trap

CGOA often tests whether candidates understand App-of-Apps as a hierarchical application management pattern rather than a build, scaling, or collaboration feature, catching those who pick answers based on superficial keyword matching.

How to eliminate wrong answers

Option A is wrong because parallel builds are a CI concern handled by build systems like Jenkins or GitHub Actions, not by Argo CD's application management pattern. Option B is wrong because increasing cluster memory is a node/infrastructure scaling task, unrelated to how Argo CD organises applications. Option D is wrong because concurrent file editing is a version-control workflow concern (e.g., Git branching), not what App-of-Apps addresses.

Practice this question →

66

MCQmedium

Why is 'Git' used as the source of truth rather than a standard database?

A.Git is the only format Kubernetes supports

B.Git is easier to host on-premise

C.Git provides native versioning, history, and collaboration

D.Git is faster at read operations

AnswerC

Git supplies native versioning, full commit history and branching, enabling collaboration, review and rollback of declarative configuration. A standard database lacks these built-in audit and merge capabilities, so Git better serves as the single source of truth for GitOps.

Why this answer

Git is used as the source of truth because it natively provides versioning, full history, branching, and collaboration workflows (pull requests, reviews, merges) that a standard database does not offer out of the box. These properties make configuration changes auditable, reviewable, and reversible — the foundation of GitOps.

Exam trap

CGOA often tests why Git specifically is chosen — the trap is picking options about hosting or performance when the real answer is Git's native versioning and collaboration model.

How to eliminate wrong answers

Option A is wrong because Kubernetes does not require Git at all — it accepts YAML/JSON via the API server, kubectl, Helm, or any client; Git is a GitOps choice, not a Kubernetes requirement. Option B is wrong because hosting ease is not the reason — Git can be hosted on-prem or in the cloud, but so can databases; the differentiator is versioning and collaboration. Option D is wrong because read performance is not the rationale — databases often outperform Git for reads, but GitOps values history and reviewability over raw read speed.

Practice this question →

67

Multi-Selecthard

Which THREE of the following are critical security considerations for a GitOps implementation?

Select 3 answers

A.Requiring GPG signing for commits

B.Using hardcoded passwords in Kubernetes manifests

C.Implementing RBAC for the Git repository

D.Storing secrets in external stores like HashiCorp Vault

E.Granting the GitOps operator cluster-admin access by default

AnswersA, C, D

GPG signing cryptographically verifies commit authorship, preventing forged or tampered commits from entering the repository that drives cluster state. This satisfies the integrity consideration, ensuring only trusted identities can alter the desired state that GitOps reconciles.

Why this answer

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

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

Exam trap

CGOA often tests whether candidates recognize that secrets must never live in Git even in private repos, and that the operator should not have blanket cluster-admin — the trap is treating convenience (hardcoded secrets, default admin) as acceptable.

Practice this question →

68

MCQhard

When using an 'Image Updater' with a GitOps operator, what is the automated workflow?

A.It detects new images and updates the manifest in Git

B.It manually restarts the cluster

C.It creates a backup of the cluster

D.It bypasses the git repository entirely

AnswerA

The Image Updater watches registries for new tags matching configured policies, then commits the updated image reference back into the Git manifest. The operator subsequently reconciles that commit, so Git remains the single source of truth throughout the automated workflow.

Why this answer

An Image Updater (such as Argo CD Image Updater) monitors a container registry for new image tags and, when it detects a newer version matching the configured policy, writes the updated image tag back into the Git manifest. This keeps Git as the source of truth while automating image version bumps. The GitOps operator then syncs the updated manifest to the cluster.

Exam trap

CGOA often tests whether candidates realise Image Updater commits to Git rather than directly patching the cluster, catching those who think it bypasses the GitOps workflow.

How to eliminate wrong answers

Option B is wrong because restarting the cluster is not an image-update function; Image Updater modifies manifests, not cluster lifecycle. Option C is wrong because backing up the cluster is unrelated to image updating — that is a disaster-recovery concern. Option D is wrong because bypassing Git would violate GitOps principles; Image Updater's entire purpose is to commit changes to Git so the normal reconciliation loop can deploy them.

Practice this question →

69

Multi-Selecthard

Which THREE of the following are best practices for managing GitOps secrets?

Select 3 answers

A.Share secrets in cleartext via team chat

B.Encrypt secrets using tools like SealedSecrets

C.Use an external secret manager like HashiCorp Vault

D.Rotate secrets regularly based on security policies

E.Store base64 encoded secrets in Git

AnswersB, C, D

SealedSecrets encrypts values with a controller-held asymmetric key, so the ciphertext is safe to commit alongside manifests. This satisfies the stem's GitOps constraint that secrets must live in Git while remaining unreadable to anyone lacking the in-cluster private key, unlike plaintext Secrets or external references.

Why this answer

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

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

Exam trap

CGOA often tests the misconception that base64 encoding provides security, when it is merely an encoding scheme that anyone can decode with a single command.

Practice this question →

70

MCQeasy

An administrator notices that the 'sync' status of an Argo CD application is 'Synced' but the health status is 'Degraded'. What does this indicate?

A.The Argo CD controller has crashed

B.The Git repository is unreachable

C.Git and the cluster state are mismatched

D.The application is correctly defined in Git but is failing at runtime

AnswerD

Sync compares live manifests against Git; health assesses workload runtime. Synced confirms the desired manifests are applied, yet Degraded reveals pods failing readiness, crashing, or otherwise unhealthy — so the definition matches Git while execution fails.

Why this answer

A 'Synced' sync status means the live cluster resources match the desired manifests in Git — there is no configuration drift. A 'Degraded' health status, however, is reported by Argo CD's health assessment (based on resource readiness, e.g., a Deployment with unavailable replicas or a Pod in CrashLoopBackOff) and indicates the workloads are not functioning correctly at runtime. Together they signal that the desired state was applied successfully but the application itself is failing.

Exam trap

CGOA often tests the orthogonality of sync status and health status; candidates mistakenly equate 'Synced' with 'healthy' and pick the drift-related answer instead of the runtime-failure answer.

How to eliminate wrong answers

Option A is wrong because if the Argo CD controller had crashed, the Application status would be stale or unreported entirely, not freshly evaluated as Synced/Degraded. Option B is wrong because an unreachable Git repository produces a 'Unknown' or 'ComparisonError' sync status, not 'Synced' — Argo CD cannot confirm sync without reading Git. Option C is wrong because a Git-versus-cluster mismatch is precisely what 'OutOfSync' represents; 'Synced' explicitly means no such mismatch exists.

Practice this question →

Ready to test yourself?

Try a timed practice session using only Gitops Terminology questions.

Start 20-question session