Courseiva

CCNA Gitops Principles Questions

26 of 101 questions · Page 2/2 · Gitops Principles topic · Answers revealed

Practice these questionsExam hubAll questions
76
MCQeasy

A developer updates a Helm release values file in Git to change a ConfigMap key. How does the GitOps pull-based agent determine that reconciliation is necessary?

A.The container registry notifies the GitOps agent whenever a ConfigMap is altered in the source code.
B.The Kubernetes API server continuously queries the Git repository directly without using any controller.
C.The agent continuously compares the target Git repository commit SHA and state against the cluster's actual state.
D.The agent receives an SSH trigger sent manually by the developer from their workstation.
AnswerC

A pull-based GitOps agent polls the Git repository, comparing the desired commit SHA and rendered manifests against live cluster objects. Any divergence in the tracked commit or resource state triggers reconciliation, applying the updated ConfigMap key to match Git.

Why this answer

GitOps agents like Argo CD and Flux continuously compare the desired state defined by the target Git commit (SHA) against the actual state in the cluster. When the values file changes, the commit SHA changes, the rendered manifests differ, and the controller detects the divergence and triggers reconciliation to apply the new ConfigMap.

Exam trap

CGOA often tests whether candidates understand that reconciliation is driven by the controller comparing Git commit/state to cluster state — not by registries, the API server, or manual developer triggers.

How to eliminate wrong answers

Option A is wrong because container registries store images, not ConfigMaps, and they do not notify GitOps agents about source code changes — that is not part of the GitOps model. Option B is wrong because the Kubernetes API server does not query Git repositories; it has no built-in Git client, and reconciliation is performed by the GitOps controller, not the API server. Option D is wrong because GitOps is pull-based and automated; it does not depend on a developer manually sending an SSH trigger from their workstation.

Practice this question →
77
Multi-Selecteasy

Which THREE of the following are common GitOps tools used in the CNCF ecosystem?

Select 3 answers
A.Crossplane.
B.Flux.
C.Apache HTTP Server.
D.Argo CD.
E.MySQL.
AnswersA, B, D

Crossplane qualifies as a CNCF GitOps tool because it extends Kubernetes' reconciliation loop to provision and manage external cloud infrastructure declaratively. Its controllers continuously compare desired state, stored as Kubernetes custom resources in Git, against actual infrastructure, correcting drift automatically — satisfying the stem's requirement for CNCF-ecosystem GitOps tooling.

Why this answer

Crossplane (A) is a CNCF project that extends Kubernetes with custom resources to provision and manage cloud infrastructure declaratively, making it a common GitOps tool for infrastructure-as-code workflows. Flux (B) is a CNCF graduated project that continuously reconciles Kubernetes cluster state with Git repositories, embodying the core GitOps pull-based model. Argo CD (D) is also a CNCF graduated project that performs declarative, Git-based continuous delivery for Kubernetes by syncing cluster resources to a desired state stored in Git.

Apache HTTP Server (C) is a general-purpose web server and MySQL (E) is a relational database; neither is a GitOps reconciliation or continuous delivery tool, so they do not belong in this list.

Exam trap

CGOA often tests whether candidates can distinguish CNCF GitOps projects from unrelated infrastructure software, so any familiar-sounding server or database name is a distractor.

Practice this question →
78
MCQmedium

What is the recommended way to handle secrets in GitOps?

A.Commit them directly to the repo in a private branch.
B.Use an encrypted secret operator like SealedSecrets.
C.Create them manually using kubectl.
D.Store them in base64 in Git.
AnswerB

GitOps requires all state to live in Git, but plaintext secrets there would be exposed. SealedSecrets encrypts them so only the in-cluster controller can decrypt, letting encrypted manifests be committed safely while preserving the Git source of truth.

Why this answer

SealedSecrets (and similar operators like SOPS, External Secrets) allow secrets to be safely stored in Git by encrypting them with a public key; only the controller in the cluster can decrypt them with its private key. This preserves GitOps principles—everything is declarative and version-controlled—while keeping plaintext secrets out of the repository. The sealed secret is safe to commit even to a public repo because it can only be decrypted by the target cluster's controller.

Exam trap

CGOA often tests the misconception that base64 encoding or private Git branches provide sufficient secrecy, when in fact only encryption with a cluster-side decryption mechanism satisfies GitOps security requirements.

How to eliminate wrong answers

Option A is wrong because committing secrets directly to a private branch still stores plaintext credentials in Git history, which is accessible to anyone with repo read access and persists even after deletion. Option C is wrong because manually creating secrets with kubectl breaks GitOps: the cluster state diverges from the declared state in Git, and the secret is not version-controlled or auditable. Option D is wrong because base64 is an encoding, not encryption—anyone can trivially decode it with `base64 -d`, so it provides zero confidentiality.

Practice this question →
79
MCQhard

In GitOps, what does 'Self-Healing' mean?

A.The cluster reboots itself if it runs out of memory.
B.The controller replaces manual changes with the state from Git.
C.The application restarts if a pod crashes.
D.The developer re-pushes the code to fix the bug.
AnswerB

A GitOps controller continuously reconciles live cluster state against the desired state declared in Git, so any manual drift is automatically reverted to match the repository. This satisfies the self-healing constraint: unauthorised or accidental changes are overwritten by the controller, restoring the Git-declared configuration without human intervention.

Why this answer

Self-healing in GitOps means the controller continuously reconciles the live cluster state against the desired state in Git and automatically reverts any manual or out-of-band changes. If someone edits a Deployment with kubectl, the controller detects the drift and restores the Git-declared state.

Exam trap

CGOA often tests the misconception that self-healing refers to pod restarts or node reboots, when it specifically means the GitOps controller reverting manual drift back to the Git-declared state.

How to eliminate wrong answers

Option A is wrong because cluster reboots due to memory pressure are a node-level concern (kubelet eviction, OOM killer), not GitOps self-healing. Option C is wrong because pod restarts on crash are handled by Kubernetes controllers (ReplicaSet, Deployment) and liveness probes, not by GitOps reconciliation. Option D is wrong because a developer re-pushing code is a manual remediation, which is the opposite of self-healing — GitOps self-healing is automatic and controller-driven.

Practice this question →
80
Multi-Selecthard

Which THREE mechanisms can be used to notify a GitOps controller of a change in Git?

Select 3 answers
A.SSH-based push from the local machine.
B.Git repository webhooks.
C.Manual refresh request via CLI/UI.
D.Periodic polling of the Git repository.
E.Waiting for a container crash.
AnswersB, C, D

Git repository webhooks push an HTTP POST to the GitOps controller the moment a commit lands, satisfying the requirement for event-driven notification rather than polling. This gives near-instant reconciliation, unlike scheduled pulls, and works with any Git host that supports outbound webhook delivery.

Why this answer

Option B (Git repository webhooks) is correct because a Git host such as GitHub, GitLab, or Bitbucket can send an HTTP POST webhook to the GitOps controller's receiver endpoint whenever a push or merge occurs, triggering immediate reconciliation. Option C (Manual refresh request via CLI/UI) is correct because tools like Argo CD and Flux expose commands such as `argocd app get --refresh` or a UI refresh button that force the controller to re-check Git on demand. Option D (Periodic polling of the Git repository) is correct because GitOps controllers run a reconciliation loop that polls the Git repository at a configured interval (e.g., Argo CD's default 3 minutes or Flux's `--poll-interval`) to detect new commits.

Option A is not a notification mechanism to the controller; an SSH push only updates the remote repository and does not itself inform the GitOps controller. Option E is incorrect because a container crash is an unrelated runtime failure and does not signal a Git change to the controller.

Exam trap

CGOA often tests whether candidates confuse the act of pushing code to Git (developer action) with the mechanism that notifies the GitOps controller (webhook/poll/refresh) — the push itself is not a notification.

Practice this question →
81
MCQhard

You are debugging a GitOps deployment. The controller shows 'OutOfSync' but the cluster seems to be running correctly. What is the most likely cause?

A.The network latency to the Git server is too high.
B.Manual changes were made to the live resource that weren't captured in Git.
C.The Git repository is empty.
D.The controller is broken.
AnswerB

OutOfSync with a healthy running workload indicates the live object's spec no longer matches the Git manifest, typically because someone edited it directly with kubectl. The controller compares desired versus observed state, so divergence alone triggers OutOfSync regardless of whether pods are actually serving traffic.

Why this answer

An 'OutOfSync' status means the live cluster state diverges from the desired state declared in Git. If the cluster is running correctly, the most common cause is that someone made manual changes (kubectl edit, kubectl apply, or a hotfix) directly to the live resource, so the controller detects drift between Git and the cluster. The controller is functioning as designed by flagging the discrepancy.

Exam trap

CGOA often tests the misconception that OutOfSync always means a controller or Git problem, when the most frequent real-world cause is manual drift in the live cluster.

How to eliminate wrong answers

Option A is wrong because network latency to the Git server would cause sync failures or timeouts, not a clean OutOfSync status with a healthy running workload. Option C is wrong because an empty Git repository would typically produce a missing-manifest or prune-related error, not a running-but-divergent state. Option D is wrong because a broken controller would fail to reconcile at all, not correctly report drift.

Practice this question →
82
Multi-Selecthard

Which THREE are standard ways to implement GitOps with Helm?

Select 3 answers
A.Running 'helm upgrade' manually.
B.Only storing the chart source code.
C.Using a GitOps operator to trigger 'helm install'.
D.Storing the final rendered YAML in Git.
E.Storing Helm values files in Git.
AnswersC, D, E

A GitOps operator such as Argo CD or Flux reconciles cluster state against Git, then triggers `helm install` (or `helm upgrade`) to render and apply charts. This satisfies the stem's requirement for a standard Helm-based GitOps pattern, since the operator automates installation directly from the declared Git source.

Why this answer

Option C is correct because GitOps operators such as Argo CD or Flux watch a Git repository and automatically trigger Helm operations like 'helm install' or 'helm upgrade' when the desired state changes, which is the core GitOps reconciliation loop. Option D is correct because storing the final rendered YAML manifests in Git is a valid GitOps pattern (often called 'rendered manifests' or 'last-mile' GitOps), where the cluster state is applied directly from committed YAML without Helm running in the cluster. Option E is correct because storing Helm values files in Git is a standard GitOps approach where the chart is referenced from a chart repository and the environment-specific values are version-controlled, allowing the operator to render and apply the release.

Option A is not a GitOps implementation because running 'helm upgrade' manually is an imperative, human-driven action that bypasses Git as the single source of truth. Option B is not a complete GitOps implementation because storing only the chart source code without values, rendered manifests, or an automated operator does not provide the declarative, continuously reconciled deployment that GitOps requires.

Exam trap

CGOA often tests the misconception that GitOps-with-Helm requires manual 'helm install/upgrade' — candidates miss that operators render charts declaratively and that committing rendered YAML is a legitimate pattern.

Practice this question →
83
MCQmedium

An administrator notices that an engineer manually modified a Service loadBalancerIP in the Kubernetes live cluster using 'kubectl edit'. The cluster is managed by an automated GitOps engine configured in a pull-based model. What will happen during the next reconciliation cycle?

A.The GitOps engine will automatically commit the updated loadBalancerIP back to the Git repository to keep Git in sync.
B.The live cluster modification will block future Git commits from being fetched by the GitOps agent.
C.The GitOps engine will detect the drift and overwrite the live cluster state to match the declared state in Git.
D.The GitOps engine will halt reconciliation permanently until an administrator manually clears the cluster error log.
AnswerC

A pull-based GitOps engine continuously compares live state against the declared state in Git. Any manual drift, such as an edited loadBalancerIP, is reverted because Git remains the single source of truth; the reconciler reapplies the manifest, overwriting the unauthorised change.

Why this answer

In a pull-based GitOps model, the engine (e.g., Argo CD or Flux) continuously compares the live cluster state to the desired state declared in Git. When it detects drift—such as a manually edited loadBalancerIP—it overwrites the live resource to match Git, provided auto-sync/self-heal is enabled. Git is never updated from the cluster; the flow is one-directional from Git to cluster.

Exam trap

CGOA often tests whether candidates believe GitOps engines write cluster changes back to Git or halt on drift, when in fact they overwrite live state to match Git—so remember reconciliation is one-way: Git to cluster.

How to eliminate wrong answers

Option A is wrong because GitOps engines do not commit live-cluster changes back to Git; the flow is unidirectional from Git to cluster, and writing back would violate the source-of-truth principle. Option B is wrong because a live modification does not block the agent from fetching Git commits; the agent continues to pull and reconcile regardless of drift. Option D is wrong because reconciliation does not halt permanently on drift; the controller simply re-applies the Git-declared state, and only pauses if there is a persistent sync error requiring intervention.

Practice this question →
84
MCQeasy

Which of the following is NOT a benefit of the GitOps model?

A.Increased system performance.
B.Improved auditability.
C.Faster recovery from disasters.
D.Standardized deployment processes.
AnswerA

GitOps governs deployment workflows and reconciliation of desired state; it does not tune runtime resources, so increased system performance is not a benefit it delivers. The other listed gains concern delivery speed, auditability and consistency.

Why this answer

GitOps is a deployment and operational model that uses Git as the single source of truth for declarative infrastructure and applications. Its primary benefits are improved auditability (every change is a Git commit), faster disaster recovery (the desired state can be reapplied from Git), and standardized deployment processes (consistent workflows across environments). Increased system performance is not a benefit of GitOps; performance depends on application design, resource allocation, and infrastructure, not on how deployments are managed.

Exam trap

CGOA often tests the misconception that GitOps directly improves system performance, when in fact it is an operational model focused on deployment, auditability, and recovery, not runtime performance.

How to eliminate wrong answers

Option B is wrong because improved auditability is a core benefit: Git history provides a complete, immutable record of all changes, including who made them and when. Option C is wrong because faster recovery from disasters is a key advantage: since the desired state is stored in Git, recovery involves simply reapplying that state, often automatically via a GitOps operator. Option D is wrong because standardized deployment processes are a direct outcome: GitOps enforces a consistent, declarative deployment pipeline across all environments.

Practice this question →
85
MCQhard

What is a 'GitOps Operator'?

A.A software agent that monitors Git and the cluster to maintain state alignment.
B.A tool that converts YAML to JSON.
C.A database that stores configuration history.
D.A human user who manually pushes Git commits.
AnswerA

A GitOps operator is a controller running in the cluster that continuously reconciles live state against the desired state declared in Git. It detects drift between the repository and cluster resources, then applies or reverts changes so the cluster converges on the committed configuration automatically.

Why this answer

A GitOps operator is a software agent, such as Argo CD or Flux, that runs inside or alongside the cluster and continuously monitors both Git and the cluster to maintain state alignment. It reconciles the desired state defined in Git with the actual state in the cluster, automatically correcting drift. This agent-based reconciliation is the defining characteristic of GitOps.

Exam trap

CGOA often tests the misconception that a GitOps operator is a human role or a simple conversion tool — the key is that it is an automated agent performing continuous reconciliation.

How to eliminate wrong answers

Option B is wrong because converting YAML to JSON is a data format transformation task, not the function of a GitOps operator; operators work with manifests in their native formats. Option C is wrong because a database that stores configuration history describes a version control system like Git itself, not the operator; the operator consumes Git but is not a database. Option D is wrong because a human user manually pushing commits is the opposite of GitOps automation — the operator is an automated software agent, not a person.

Practice this question →
86
MCQeasy

What is the relationship between the 'desired state' and the 'actual state' in GitOps?

A.The controller continuously reconciles the actual state to the desired state.
B.The desired state is defined by the actual state.
C.The desired state is enforced by the controller to match the actual state.
D.The actual state is manually pushed to the desired state.
AnswerA

Git holds the desired state as the single source of truth, while the cluster's live objects form the actual state. The controller continuously compares and reconciles the actual state toward the desired state, which is the defining GitOps relationship.

Why this answer

In GitOps, Git holds the declarative desired state, and a controller (e.g., Argo CD or Flux) continuously compares it against the live actual state, reconciling any differences so the cluster converges on Git. This continuous reconciliation loop is the defining mechanism of GitOps.

Exam trap

CGOA often tests the direction of reconciliation — candidates confuse whether the controller pushes desired state to the cluster or pulls actual state into Git, when the correct model is Git as source of truth driving the cluster toward it.

How to eliminate wrong answers

Option B is wrong because it inverts the relationship — the desired state is authored in Git by humans/CI, not derived from the running cluster. Option C is wrong because it reverses the direction of enforcement; the controller makes the actual state match the desired state, not the other way around. Option D is wrong because GitOps is declarative and automated, not a manual push of live state into Git; manual drift commits would defeat the purpose of continuous reconciliation.

Practice this question →
87
Multi-Selectmedium

Which TWO of the following are primary benefits of storing immutable state in Git?

Select 2 answers
A.Reduction in manual cluster configuration errors
B.Faster deployment of hotfixes directly to production
C.Automated conversion of Docker images to YAML
D.Ability to audit all environment changes through commit history
E.Increased server-side storage capacity
AnswersA, D

Storing immutable state in Git eliminates manual cluster configuration errors because every change is versioned, peer-reviewed and revertible, rather than applied by hand. Git's commit history provides an auditable record, so drift and fat-fingered edits are caught before reaching production, satisfying the stem's requirement for reduced human error.

Why this answer

Option A is correct because storing immutable state in Git (the GitOps model) makes the desired cluster configuration declarative and version-controlled, so changes are reviewed and applied consistently, which reduces manual, error-prone cluster configuration. Option D is correct because every change to the desired state is a Git commit, giving a complete, auditable history of who changed what and when, enabling rollback and traceability of all environment changes. Option B is not a primary benefit of immutable Git state, since hotfix speed depends on the CI/CD pipeline and deployment process, not on storing state in Git.

Option C is incorrect because Git does not automatically convert Docker images into YAML manifests; that requires separate tooling. Option E is incorrect because Git stores configuration, not server storage capacity, so it does not increase server-side storage.

Exam trap

The trap here is selecting benefits that sound plausible but are not directly related to immutability in Git, such as faster hotfix deployment or storage capacity, rather than focusing on error reduction and auditability.

Practice this question →
88
Multi-Selectmedium

Which TWO are examples of 'Drift' in a GitOps environment?

Select 2 answers
A.A temporary spike in CPU usage.
B.A manual update to a Deployment image via kubectl.
C.A container crashing due to a code bug.
D.A new Git commit.
E.Changing a Service type directly in the cluster.
AnswersB, E

Running kubectl to change a Deployment's image bypasses Git, so the live cluster diverges from the declared desired state. The GitOps operator detects this mismatch and reverts it, which is precisely the drift condition the question describes.

Why this answer

In GitOps, drift is any divergence between the desired state stored in Git and the actual state running in the cluster. Option B is correct because running kubectl to change a Deployment's image modifies the live cluster state outside of Git, so the actual state no longer matches the declared manifest, which is classic configuration drift. Option E is correct because editing a Service type directly in the cluster (e.g., changing ClusterIP to NodePort) also bypasses Git and creates a mismatch between the declared and observed state.

Option A is not drift because a CPU spike is a transient runtime metric, not a configuration divergence from Git. Option C is not drift because a container crash is an application/runtime failure, not a change to the declared desired state. Option D is not drift because a new Git commit updates the desired state itself and is the normal GitOps change mechanism, not a divergence from it.

Exam trap

CGOA often tests the misconception that runtime events like CPU spikes or crashes constitute drift, when drift is strictly a configuration divergence from Git.

Practice this question →
89
Multi-Selecthard

A senior cloud architect is designing a multi-tenant platform using GitOps. They want to ensure that continuous drift detection and correction operate reliably without causing system instability. Which TWO practices help mitigate risks associated with automated continuous drift correction?

Select 2 answers
A.Granting full cluster-admin permissions to all application developers so they can manually disable drift correction during deployments.
B.Disabling Git versioning so that drift detection compares live state against an unversioned NFS network share.
C.Configuring the GitOps controller to ignore specific dynamic fields updated by in-cluster controllers, such as 'spec.replicas' managed by a HorizontalPodAutoscaler (HPA).
D.Setting the reconciliation loop interval to run once every 30 seconds while forcing a full cluster node reboot on every iteration.
E.Utilizing dry-run or diff-matching alerts to notify teams of unexpected drift before automated self-healing applies destructive changes to critical resources.
AnswersC, E

Excluding fields such as spec.replicas prevents the controller from reverting legitimate changes made by the HorizontalPodAutoscaler, which would otherwise cause scaling thrash. This satisfies the stem's requirement to avoid instability during continuous drift correction, since only genuinely drifted fields are reconciled.

Why this answer

Option C is correct because GitOps controllers such as Argo CD or Flux continuously reconcile live state to Git, and fields like 'spec.replicas' that are legitimately mutated by an in-cluster controller (an HPA) will otherwise be perpetually reverted, causing a fight between controllers and instability; configuring ignoreDifferences (Argo CD) or equivalent field exclusions prevents this. Option E is correct because running drift detection in a non-mutating mode first — Argo CD's diff view or sync with --dry-run, or alerting on OutOfSync status — surfaces unexpected drift to teams before self-healing applies destructive changes (e.g., deleting or recreating critical resources), which is the standard risk-mitigation pattern for automated correction. Option A is wrong because granting cluster-admin to all developers and allowing manual disabling of drift correction destroys the security model and auditability of GitOps rather than mitigating risk.

Option B is wrong because removing Git versioning and comparing against an unversioned NFS share eliminates the single source of truth, rollback capability, and drift provenance that GitOps depends on. Option D is wrong because a 30-second reconciliation interval with a full node reboot per iteration is operationally catastrophic and would itself cause the instability the architect is trying to avoid.

Exam trap

CGOA often tests whether candidates understand that not all drift should be auto-corrected — the trap is assuming more aggressive reconciliation and broader permissions always improve reliability, when in fact ignoring controller-managed fields and previewing changes are the safer practices.

Practice this question →
90
MCQhard

You are implementing a GitOps pipeline for a complex microservices architecture. To satisfy the principle of 'versioned and immutable state', how should you handle environment-specific configurations while maintaining a single source of truth?

A.Use Kustomize overlays to manage environment-specific patches stored in the same repository
B.Use a CI pipeline to inject environment variables into the cluster via API calls
C.Execute helm install --set commands during the deployment phase
D.Maintain separate Git repositories for every environment
AnswerA

Kustomize overlays keep a single base manifest while environment-specific patches remain declarative files in the same repository, so every change is versioned in Git and immutable once committed. This satisfies the stem's single-source-of-truth constraint without duplicating manifests or introducing mutable runtime configuration.

Why this answer

Kustomize overlays allow you to manage environment-specific configurations as patches stored in the same Git repository, maintaining a single source of truth while avoiding duplication. This aligns with GitOps principles of versioned and immutable state because all configurations are declarative, version-controlled, and can be reviewed. Overlays let you customize base manifests for dev, staging, and prod without branching or separate repos.

Exam trap

CGOA often tests the difference between declarative configuration stored in Git (Kustomize overlays) and imperative commands (helm --set, CI injections), trapping candidates who think any automation is GitOps.

How to eliminate wrong answers

Option B is wrong because injecting environment variables via CI API calls is imperative and not stored in Git, violating the single source of truth and immutability. Option C is wrong because helm install --set commands are imperative and not versioned in Git; they also bypass declarative state management. Option D is wrong because maintaining separate Git repositories per environment fragments the source of truth and complicates synchronization, making it harder to ensure consistency and audit changes.

Practice this question →
91
MCQmedium

In a GitOps environment, an engineer manually deletes a Deployment via 'kubectl'. What should happen next to maintain the desired state?

A.The controller detects the drift and automatically restores the Deployment.
B.The controller ignores the change until the next git commit.
C.The system issues an alert but does not modify the cluster.
D.The manual deletion is permanently synced to the Git repository.
AnswerA

The GitOps controller continuously compares live cluster state against the Git-declared desired state. Deleting the Deployment creates drift, so the controller's reconciliation loop recreates the missing resource automatically, restoring the declared state without manual intervention.

Why this answer

In a GitOps environment, the GitOps controller continuously reconciles the actual state of the cluster with the desired state stored in Git. When a Deployment is manually deleted, the controller detects the drift and automatically recreates it to match the Git manifest. This self-healing behavior is a core principle of GitOps.

Exam trap

CGOA often tests the self-healing aspect of GitOps; candidates may think manual changes are ignored or require a Git commit, but the controller actively reverts drift.

How to eliminate wrong answers

Option B is wrong because the controller does not wait for a Git commit; it continuously monitors and reconciles. Option C is wrong because the controller not only alerts but also takes corrective action to restore the desired state. Option D is wrong because manual changes are not synced to Git; Git remains the single source of truth, and the controller reverts the cluster to match Git.

Practice this question →
92
MCQhard

You are troubleshooting a Flux controller that is not reconciling changes. The Git repository is updated, but the cluster remains unchanged. Which component should you inspect first to verify the 'automated pull-based reconciliation'?

A.The Kubernetes API server logs.
B.The 'flux-system' namespace's 'kustomization.yaml' file.
C.The Git provider's webhook logs.
D.The 'GitRepository' or 'Kustomization' custom resources.
AnswerD

Flux's GitRepository and Kustomization custom resources are the declarative objects that bind a Git source to cluster reconciliation. Inspecting their status reveals whether the source was fetched and whether the Kustomization applied it, directly verifying the automated pull-based reconciliation the stem describes.

Why this answer

Flux's reconciliation is driven by custom resources: 'GitRepository' defines the source (repo URL, branch, credentials) and 'Kustomization' defines what to apply and how. If Git is updated but the cluster is unchanged, inspecting these CRs with 'kubectl get gitrepository,kustomization -n flux-system' and their status conditions reveals whether the source was fetched and whether the apply succeeded. This is the first diagnostic step because it directly reflects the reconciliation pipeline.

Exam trap

CGOA often tests whether candidates know that Flux reconciliation state lives in custom resources (GitRepository, Kustomization) rather than in generic Kubernetes components like the API server or Git webhooks — picking the wrong layer wastes troubleshooting time.

How to eliminate wrong answers

Option A is wrong because the Kubernetes API server logs record request handling, not Flux's source-fetching or reconciliation logic; they would not show why a Git commit was not detected. Option B is wrong because 'kustomization.yaml' inside the flux-system namespace is a file in the repo, not the runtime state — inspecting it does not reveal whether Flux actually reconciled. Option C is wrong because Flux's default reconciliation is polling-based, not webhook-driven, so Git provider webhook logs may not even exist or be relevant to the failure.

Practice this question →
93
MCQeasy

Which of the following actions best aligns with the GitOps principle of 'Automated Pull-Based Reconciliation'?

A.A developer manually running Helm upgrade in the production environment
B.Using a Git hook to trigger an SSH deployment script on a remote server
C.Jenkins triggers a 'kubectl apply' command to push changes from the CI server
D.A cluster-resident controller actively pulling manifests from a Git repository
AnswerD

A cluster-resident controller continuously pulls manifests from Git and reconciles live state against them, satisfying the pull-based requirement. Unlike push-based CI pipelines, the controller initiates the fetch from inside the cluster, so drift is detected and corrected automatically without external credentials or inbound access to the cluster.

Why this answer

Automated pull-based reconciliation means a controller running inside the cluster continuously pulls the desired state from Git and reconciles the live state to match, without external push. A cluster-resident controller pulling manifests from Git is the textbook definition of this principle.

Exam trap

The trap is equating any automated pipeline (Jenkins kubectl apply, Git hooks) with GitOps — the exam requires the pull direction and an in-cluster reconciler.

How to eliminate wrong answers

Option A is wrong because a developer manually running helm upgrade is a push-based, human-triggered action that bypasses Git as the source of truth and is not automated. Option B is wrong because a Git hook triggering an SSH deployment script is still a push model — the pipeline pushes to the server rather than the cluster pulling. Option C is wrong because Jenkins running kubectl apply is a classic CI push model; the cluster is a passive target, not an active reconciler, and credentials must be handed to the CI system.

Practice this question →
94
MCQmedium

What is the primary advantage of storing Kubernetes manifests in a version-controlled repository?

A.It makes the container images run faster.
B.It automatically patches security vulnerabilities.
C.It provides a backup in case the cluster is deleted.
D.It allows developers to bypass the CI/CD system.
AnswerC

Version control preserves every manifest revision, so the desired state can be reapplied to rebuild a cluster from scratch. That declarative source of truth, not merely a backup, is what allows recovery after deletion and consistent redeployment across environments.

Why this answer

Storing Kubernetes manifests in a version-controlled repository (e.g., Git) creates a durable, auditable record of the desired cluster state. If the cluster is deleted or corrupted, the manifests can be re-applied to rebuild the environment, effectively acting as a backup of the declarative configuration. This is a core GitOps principle: Git is the single source of truth for both application and infrastructure definitions.

Exam trap

CGOA often tests the misconception that version control automatically provides security patching or performance benefits, when its primary role is declarative state management and recovery.

How to eliminate wrong answers

Option A is wrong because container image execution speed is determined by image size, layers, and runtime resources, not by where the YAML manifests are stored. Option B is wrong because version control does not scan or patch vulnerabilities; that requires separate tooling like image scanners or admission controllers. Option D is wrong because storing manifests in Git is a prerequisite for CI/CD pipelines, not a way to bypass them; changes still flow through the pipeline for validation and deployment.

Practice this question →
95
MCQmedium

A company is choosing between a push-based CI/CD pipeline (e.g., executing 'kubectl apply' from GitHub Actions) and a pull-based GitOps controller (e.g., Argo CD or Flux). Which security advantage is uniquely provided by adopting the pull-based architecture?

A.Git repositories are automatically encrypted at rest using cluster-managed hardware security modules.
B.It eliminates the need to perform code reviews or pull request approvals before deploying to production.
C.Cluster API credentials do not need to be exposed or stored inside the external CI/CD platform.
D.Container images are automatically scanned for vulnerabilities before being pushed to the container registry.
AnswerC

In pull-based GitOps the controller runs inside the cluster and fetches from Git, so the CI platform never holds cluster API credentials. Push pipelines must store those credentials externally, widening the blast radius if the CI system is compromised.

Why this answer

The unique security advantage of pull-based GitOps is that the cluster's API credentials never leave the cluster — the in-cluster controller pulls changes from Git rather than an external system pushing into the cluster. This eliminates the need to store high-privilege kubeconfig or service account tokens in an external CI/CD platform, drastically reducing the attack surface.

Exam trap

CGOA often tests the credential-exposure distinction between push and pull models, catching candidates who pick generic security benefits like image scanning that apply to both architectures.

How to eliminate wrong answers

Option A is wrong because Git repository encryption at rest is a Git hosting concern (e.g., GitHub, GitLab) and is unrelated to the push-versus-pull deployment model. Option B is wrong because pull-based GitOps still relies on pull request reviews and code approvals — it does not remove governance; it strengthens it by making Git the audit trail. Option D is wrong because image vulnerability scanning is performed by separate tooling (Trivy, Clair, Grype) in either architecture and is not a security advantage unique to pull-based GitOps.

Practice this question →
96
MCQmedium

When utilizing Git as the 'Source of Truth' for a cluster, what happens if the cluster state diverges from Git?

A.The controller alerts the administrator but takes no action.
B.The Git repository is updated to reflect the new cluster state.
C.The controller detects the drift and reports it as out-of-sync.
D.The cluster ignores the Git repository until a new commit is pushed.
AnswerC

GitOps controllers continuously reconcile the desired manifest in Git against live cluster objects. When the running state diverges, the controller flags the resource as OutOfSync rather than silently overwriting it, satisfying the scenario's need to surface drift between Git as source of truth and the cluster.

Why this answer

In GitOps, Git is the single source of truth, and the reconciliation controller continuously compares the live cluster state against the desired state in Git. When they diverge, the controller marks the Application as OutOfSync and, depending on sync policy, may auto-heal or wait for manual sync. It never silently overwrites Git with cluster state, preserving Git's authority.

Exam trap

CGOA often tests the misconception that the controller writes cluster state back to Git or merely alerts, when the correct behavior is detecting drift and reporting OutOfSync.

How to eliminate wrong answers

Option A is wrong because the controller does more than alert; it computes a diff and exposes OutOfSync status, and with automated sync it actively remediates. Option B is wrong because GitOps is one-directional from Git to cluster; writing cluster state back to Git would invert the source of truth and is not how Argo CD or Flux behave. Option D is wrong because the controller does not ignore Git on divergence; it keeps reconciling and reports drift until the cluster matches Git or a sync is triggered.

Practice this question →
97
Multi-Selecthard

Which THREE components are essential for a robust pull-based GitOps deployment?

Select 3 answers
A.A Git repository hosting declarative manifests.
B.A Kubernetes cluster to host the applications.
C.A GitOps controller (e.g., Argo CD or Flux).
D.A continuous integration server with cluster-admin access.
E.A dedicated database for storing cluster state.
AnswersA, B, C

A Git repository holding declarative manifests is the single source of truth that pull-based GitOps agents continuously reconcile against. Without it, no desired state exists for the cluster to pull, so the stem's essential-component requirement cannot be met.

Why this answer

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

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

Exam trap

CGOA often tests the misconception that a CI server with cluster-admin access is required for GitOps, confusing push-based CI/CD with pull-based GitOps, where the controller inside the cluster pulls changes and CI is not part of the core loop.

Practice this question →
98
MCQmedium

When defining a declarative desired state in Kubernetes, which attribute is essential to satisfy the 'declarative' principle?

A.A shell script that executes 'kubectl apply'.
B.A webhook that triggers an update process.
C.A YAML manifest describing the final resource configuration.
D.A manual 'kubectl edit' command.
AnswerC

A YAML manifest declares the final resource configuration, letting Kubernetes controllers continuously reconcile actual state toward that specification. This satisfies the declarative principle's core constraint: you state the desired end state rather than issuing imperative commands, and the control plane determines and performs the steps needed to reach it.

Why this answer

The declarative principle in Kubernetes means you describe the desired end state of resources rather than the imperative steps to reach it. A YAML manifest (or JSON) expresses that final configuration, and the controller/API server reconciles actual state toward it. This is why 'kubectl apply -f manifest.yaml' is idempotent and repeatable, unlike imperative commands.

Exam trap

CGOA often tests the confusion between the tool that applies configuration (kubectl, a script, a webhook) and the declarative artifact itself — candidates pick the delivery mechanism instead of the manifest that encodes desired state.

How to eliminate wrong answers

Option A is wrong because a shell script running 'kubectl apply' is merely a delivery mechanism — the script itself is imperative and the declarative content still lives in the manifest it references. Option B is wrong because a webhook is an event trigger, not a description of desired state; it initiates a process rather than declaring an outcome. Option D is wrong because 'kubectl edit' is an imperative, interactive mutation of live state that bypasses version-controlled declarative definitions and is not reproducible.

Practice this question →
99
Multi-Selectmedium

Which TWO benefits does GitOps provide for team collaboration?

Select 2 answers
A.Removing the need for communication.
B.Forcing everyone to use the same IDE.
C.Providing a transparent, versioned history of infrastructure changes.
D.Allowing developers to deploy without oversight.
E.Enabling peer review of all changes via Merge Requests.
AnswersC, E

Because every change is a commit, Git records who changed what and when. This versioned history gives teams an auditable, transparent trail of infrastructure changes, supporting collaboration and rollback without relying on undocumented manual actions.

Why this answer

Option C is correct because GitOps stores the desired state of infrastructure as declarative configuration in a Git repository, so every change is committed with an author, timestamp, and diff, giving the whole team a transparent, versioned audit trail that can be inspected, reverted, or compared across branches and tags. Option E is correct because GitOps workflows route all changes through Git, so modifications are proposed as branches and merged via Merge Requests (or Pull Requests), enabling peer review, comments, approvals, and CI checks before anything reaches the cluster. The unmarked options do not belong: A is wrong because GitOps still requires communication for design and incident response, B is wrong because GitOps is tool-agnostic and does not mandate any IDE, and D is wrong because GitOps actually increases oversight by requiring reviewed, approved merges rather than unmonitored deployments.

Exam trap

CGOA often tests the misconception that GitOps eliminates human oversight or communication, when in fact it formalizes both through version control and merge-request workflows.

Practice this question →
100
Multi-Selecthard

Which THREE principles are foundational to the GitOps model as defined by the CNCF GitOps Working Group?

Select 3 answers
A.Manual approval is required for all production deployments
B.Software must be delivered using push-based CI/CD pipelines
C.Changes must be automatically pulled and applied
D.The state must be versioned and immutable
E.The system must be defined declaratively
AnswersC, D, E

Automatic pull-based reconciliation satisfies the CNCF principle that software agents continuously observe and reconcile desired state from Git, rather than relying on external push pipelines. This closes the loop without human intervention, ensuring the declared configuration is applied even after drift, which the stem's GitOps definition requires.

Why this answer

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

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

Exam trap

The trap here is including push-based CI/CD or manual approval as principles, which are not part of the GitOps model; candidates might confuse traditional CI/CD practices with GitOps principles.

Practice this question →
101
Multi-Selectmedium

Which TWO characteristics help ensure a GitOps repository is auditable?

Select 2 answers
A.Only allowing the admin user to push code.
B.Use of private email addresses in commit logs.
C.Cryptographically signed commits to verify authorship.
D.Detailed commit logs showing the author and time of change.
E.Storing all files as binary blobs.
AnswersC, D

Signed commits bind each change to a verified GPG key, so reviewers can prove who authored every commit. This cryptographic authorship evidence satisfies the auditability requirement, unlike unsigned history where identity can be spoofed by setting an arbitrary user.name and email.

Why this answer

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

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

Exam trap

CGOA often tests the misconception that access restriction (only admins can push) equals auditability, when auditability actually requires verifiable authorship and detailed change records.

Practice this question →
← PreviousPage 2 of 2 · 101 questions total

Ready to test yourself?

Try a timed practice session using only Gitops Principles questions.

Start 20-question session