Courseiva

CCNA Related Practices Questions

55 questions · Related Practices topic · All types, answers revealed

Practice these questionsExam hubAll questions
1
MCQhard

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

A.During the Git commit process using local pre-commit hooks.
B.In the CI pipeline during the image scanning phase.
C.At the Kubernetes API server using an Admission Controller like OPA Gatekeeper.
D.By manually reviewing the Git diffs before merging the pull request.
AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
2
MCQeasy

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

A.Because it acts as the single point of record for the desired system state.
B.Because Git stores all application logs.
C.Because it is the only tool that supports branching.
D.Because Git automatically runs the applications.
AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
3
MCQeasy

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

A.To build container images.
B.To validate and enforce policies on cluster resources before they are persisted.
C.To monitor application logs for errors.
D.To trigger the CI/CD pipeline.
AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
4
Multi-Selectmedium

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

Select 3 answers
A.Faster code compilation times compared to traditional CI systems.
B.Increased consistency between environments through standardized Git workflows.
C.Reduced need for automated security scanning.
D.Simplified disaster recovery by re-applying the Git state to a new cluster.
E.Improved auditability of changes through Git commit history.
AnswersB, D, E

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

Why this answer

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

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

Exam trap

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

Practice this question →
5
Multi-Selecthard

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

Select 2 answers
A.Addressing configuration drift caused by manual changes to the cluster.
B.Managing secrets in a secure way within the version control system.
C.The requirement to use only open-source software.
D.The speed at which Git servers process pull requests.
E.The lack of support for containerization in the organization.
AnswersA, B

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

Why this answer

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

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

Exam trap

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

Practice this question →
6
MCQhard

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

A.It causes high latency in the cluster.
B.The GitOps operator cannot detect changes.
C.It consumes too much disk space.
D.It makes rollbacks impossible because the 'latest' image may be different than what was deployed.
AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
7
MCQmedium

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

A.Require every engineer to sign a written attestation each quarter confirming they made no manual production changes.
B.Restrict kubectl access by issuing read-only kubeconfig files to all developers and operators.
C.Increase the GitOps operator's reconciliation interval from five minutes to thirty seconds so changes are corrected faster.
D.Enable drift detection and reconciliation alerts so any divergence between Git and the live cluster is recorded and surfaced.
AnswerD

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

Why this answer

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

Exam trap

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

Practice this question →
8
MCQmedium

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

A.Tag every commit that reaches production and require the operator to record the reconciled commit SHA as an annotation on each managed resource.
B.Store the operator's reconciliation logs in a central log platform with a twelve-month retention policy.
C.Require all changes to production to be applied manually with kubectl after a four-eyes review in the change advisory board.
D.Enable drift detection alerts so any divergence between Git and the cluster is reported to the team's chat channel.
AnswerA

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

Why this answer

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

Exam trap

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

Practice this question →
9
MCQhard

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

A.The container registry is unreachable during a new image rollout.
B.The Git repository contains syntax errors in the YAML files.
C.A user performed a manual 'kubectl' command to modify a deployment.
D.The CI pipeline failed to run tests.
AnswerC

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

Why this answer

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

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
10
Multi-Selectmedium

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

Select 3 answers
A.An automated controller that reconciles the cluster to the Git state.
B.A CI system that updates the manifest repository.
C.A human-operated dashboard for manual deployment.
D.A version control system (Git) acting as the source of truth.
E.A dedicated server for storing logs.
AnswersA, B, D

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

Why this answer

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

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

Exam trap

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

Practice this question →
11
Multi-Selecteasy

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

Select 2 answers
A.All code is written in Go.
B.Changes are automatically reconciled to match the declared state.
C.Manual updates are preferred for emergency fixes.
D.The desired state is defined in a version-controlled repository.
E.Developers have direct SSH access to the production cluster.
AnswersB, D

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

Why this answer

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

Exam trap

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

Practice this question →
12
MCQeasy

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

A.It replaces the need for monitoring.
B.It enables the entire infrastructure to be versioned and reconciled automatically.
C.It reduces the number of developers needed.
D.It makes the cloud provider cheaper.
AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
13
MCQeasy

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

A.Wait for the automated CI/CD tool to trigger a redeployment.
B.Submit a pull request to the Git repository containing the configuration update.
C.Run 'kubectl apply' from their local machine.
D.Log into the Argo CD dashboard and click 'Deploy'.
AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
14
MCQhard

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

A.Use Crossplane to represent infrastructure as Kubernetes objects, managing both IaC and apps via GitOps.
B.Execute Terraform via a CI job that triggers Argo CD after completion.
C.Manually trigger Terraform runs before pushing new app manifests to Git.
D.Embed Terraform binary execution within a K8s deployment container.
AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
15
MCQmedium

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

A.Having the CD operator pull the 'latest' tag directly from the registry.
B.Manually updating the YAML file with the new image tag and committing to Git.
C.Triggering a shell script to update the cluster state directly from the CI pipeline.
D.Using an automated agent that detects new images and commits the tag change back to the Git repo.
AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
16
Multi-Selecteasy

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

Select 2 answers
A.Using manual SSH access for emergency production troubleshooting.
B.Ensuring all developers have cluster-admin privileges for rapid debugging.
C.Relying primarily on graphical user interfaces for cluster management.
D.Integrating automated security policies (like OPA) into the deployment workflow.
E.Defining infrastructure as code to ensure repeatability.
AnswersD, E

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

Why this answer

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

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

Exam trap

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

Practice this question →
17
MCQeasy

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

A.It eliminates the need for container registries.
B.You can use fewer Git branches.
C.The CI system runs faster.
D.The cluster does not need inbound access from the CI pipeline.
AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
18
MCQeasy

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

A.Manually clicking buttons in a UI to scale a service.
B.Defining the desired state in a YAML file.
C.Creating a list of commands to run in order.
D.Writing a shell script to upgrade a deployment.
AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
19
MCQmedium

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

A.It is required by the Kubernetes specification.
B.Because they are written in different languages.
C.To allow different teams to manage code and configuration independently and securely.
D.It makes the CI/CD pipeline run faster.
AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
20
MCQmedium

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

A.It makes the deployment process faster.
B.It removes the need for exposed API server credentials in the CI tool.
C.It eliminates the need for Git.
D.It allows developers to push code directly to production.
AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
21
MCQeasy

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

A.Configuration as Code is only for databases.
B.Config as Code is always written in YAML.
C.They are the same thing.
D.IaC defines the underlying resources, while Config as Code defines the application-level settings.
AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
22
MCQhard

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

A.Use an external secret store that injects values into the cluster at runtime.
B.Store secrets in an encrypted cloud storage bucket and manually map them.
C.Use standard Kubernetes secrets and hope for the best.
D.Use Sealed Secrets with a public key in Git.
AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
23
MCQhard

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

A.Use a Kubernetes 'Job' resource that runs before the Deployment, and manage dependencies with initContainers or Helm hooks.
B.Add a 'kubectl apply' command to the end of the CI pipeline to execute migrations.
C.Hardcode the migration logic into the application source code to run on startup.
D.Create a manual trigger in the GitOps dashboard to execute the migration after the deployment starts.
E.Configure the GitOps agent to execute a shell script on the node before pulling the image.
AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

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

Practice this question →
24
MCQhard

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

A.Revert the commit in Git and let the GitOps operator reconcile.
B.Delete the pods and let the operator recreate them.
C.Stop the GitOps operator to prevent it from correcting the state.
D.Run 'kubectl rollout undo' on the deployment.
AnswerA

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

Why this answer

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

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
25
MCQhard

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

A.Tag the current application repo commit as production and let each cluster's operator resolve the newest matching image automatically.
B.Copy the application manifests from staging directly into the production namespace using kubectl apply.
C.Rebuild the container image in the production pipeline to guarantee the artifact matches the production environment.
D.Open a pull request against the environment repo updating the production image digest to the value validated in staging.
AnswerD

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

Why this answer

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

Exam trap

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

Practice this question →
26
MCQmedium

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

A.Secrets are encrypted in the Git repo.
B.The cluster automatically reconciles changes pushed to Git.
C.Developers use PRs to propose changes to the environment.
D.An administrator manually updates a Kubernetes Deployment manifest directly on the cluster.
AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
27
MCQhard

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

A.The deployment process automatically commits changes back to the same Git branch that triggers the deployment.
B.The cluster is too small.
C.The Git repository contains a circular reference.
D.The container registry is offline.
AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
28
MCQeasy

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

A.Everything, including image building and deployment, must be handled by the GitOps controller.
B.The CI pipeline should perform the final deployment to ensure the pipeline status is correctly reported.
C.Container image building and unit testing remain in CI, while manifest deployment to the cluster moves to GitOps.
D.Container image building moves to GitOps, while manifest deployment remains in the CI pipeline.
AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
29
MCQmedium

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

A.The GitOps operator will enter a 'halt' state and require manual intervention to synchronize.
B.The GitOps operator will detect the drift and revert the manual change to match the configuration in Git.
C.The GitOps operator will trigger an alert, but the manual change will remain in place until the next deployment.
D.The GitOps operator will automatically update the Git repository to reflect the manual change.
AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
30
MCQmedium

What is the best way to handle temporary, non-production overrides in a GitOps environment?

A.Hardcoding all variants into the base file using if/else statements.
B.Leaving the cluster in a drifted state.
C.Editing the base manifest and pushing it.
D.Using Kustomize overlays to apply overrides on top of the base configuration.
AnswerD

Kustomize overlays layer environment-specific patches over an unchanged base, so temporary non-production overrides stay declarative and version-controlled without forking the base manifests. This satisfies the GitOps constraint that all desired state, including short-lived deviations, remains reconciled from Git rather than applied imperatively.

Why this answer

Kustomize overlays are the canonical GitOps pattern for environment-specific overrides: a shared base holds common manifests, and overlays patch only the fields that differ per environment (replicas, image tags, resource limits). This keeps the base DRY and the overrides declarative and version-controlled. Overlays are applied by the CD controller during reconciliation, so no manual drift is introduced.

Exam trap

CGOA often tests the misconception that editing the base manifest or hardcoding conditionals is acceptable for environment overrides, when the correct pattern is non-destructive overlays that leave the base intact.

How to eliminate wrong answers

Option A is wrong because hardcoding all variants into a base file with if/else logic is not possible in plain YAML/Kustomize and produces an unmaintainable, error-prone manifest that defeats the purpose of a clean base. Option B is wrong because leaving the cluster in a drifted state violates GitOps principles — the controller will detect and revert the drift, and the override is not reproducible or auditable. Option C is wrong because editing the base manifest and pushing it changes the shared configuration for all environments, not just the temporary non-production one, causing unintended production impact.

Practice this question →
31
MCQeasy

In the context of 'Configuration as Code', why is it considered a best practice to use a declarative manifest format (like YAML) rather than imperative commands?

A.It is easier to type YAML than complex CLI commands.
B.Declarative manifests represent the desired state, allowing for automated drift detection and reconciliation.
C.YAML files are automatically encrypted by the GitOps provider.
D.Imperative commands are not supported by the Kubernetes API.
AnswerB

Declarative manifests describe the target state rather than the steps to reach it, so a controller can compare actual versus desired state and reconcile differences. This enables automated drift detection, which imperative commands cannot provide since they execute once without ongoing state comparison.

Why this answer

Declarative manifests like YAML are preferred because they express the desired end state of the system, enabling the GitOps controller to continuously compare actual state to desired state, detect drift, and automatically reconcile. This is the foundation of GitOps' self-healing and auditability. Imperative commands, by contrast, describe steps to execute and leave no persistent desired-state record for reconciliation.

Exam trap

CGOA often tests the conceptual distinction between declarative (desired state, reconciliation) and imperative (step-by-step commands) approaches, so candidates who pick convenience-based or factually incorrect options miss the architectural rationale.

How to eliminate wrong answers

Option A is wrong because ease of typing is a superficial convenience, not the architectural reason declarative formats are best practice; the real value is desired-state representation and reconciliation. Option C is wrong because YAML files are not automatically encrypted by GitOps providers; secrets in YAML must be encrypted explicitly using tools like SOPS or Sealed Secrets. Option D is wrong because the Kubernetes API absolutely supports imperative commands (e.g., kubectl run, kubectl create), so this statement is factually incorrect.

Practice this question →
32
MCQmedium

Which tool provides the most native integration for managing Kubernetes manifests using Kustomize within a GitOps workflow?

A.Terraform
B.Ansible
C.Jenkins
D.Argo CD
AnswerD

Argo CD natively renders Kustomize overlays as a first-class manifest source, applying kustomization.yaml builds during sync without extra plugins or wrapper tooling. This makes it the most integrated GitOps controller for managing Kustomize-based Kubernetes manifests declaratively.

Why this answer

Argo CD is purpose-built for GitOps and natively supports Kustomize as a first-class manifest source. Its repository server recognizes kustomization.yaml files and can render Kustomize overlays directly without external tooling. Terraform, Ansible, and Jenkins are general-purpose automation tools that require custom glue code to invoke Kustomize and do not provide continuous reconciliation of Kustomize-rendered manifests.

Exam trap

CGOA often tests whether candidates confuse general CI/CD or IaC tools (Terraform, Ansible, Jenkins) with GitOps-native controllers that have built-in Kustomize rendering, so pick the tool whose controller actually reconciles Kustomize output.

How to eliminate wrong answers

Option A is wrong because Terraform is an infrastructure-as-code provisioner that manages resources via providers and state files; it has no native Kustomize renderer and would require external data sources or local-exec provisioners to invoke Kustomize. Option B is wrong because Ansible is a configuration management tool that executes playbooks; it can shell out to 'kustomize build' but offers no native manifest rendering or GitOps reconciliation. Option C is wrong because Jenkins is a CI orchestration server that runs pipeline jobs; it can trigger kubectl/kustomize commands but provides no continuous drift detection or GitOps controller behavior.

Practice this question →
33
MCQeasy

A team adopting GitOps wants to reduce the blast radius of a bad change and shorten mean time to recovery. They already store all manifests in Git and use an operator for reconciliation. Which practice most directly limits the impact of a faulty change reaching production?

A.Grant all engineers write access to the production cluster so they can patch issues directly.
B.Increase the reconciliation interval so the operator checks Git less frequently.
C.Store manifests in a single branch and disable pull request reviews to speed up merges.
D.Use progressive delivery with canary or blue-green rollouts gated by automated health checks.
AnswerD

Progressive delivery exposes a new version to a small subset of traffic or a shadow environment first, then promotes it only if health and error-rate checks pass. A faulty change is caught while affecting few users and is automatically halted or rolled back, directly shrinking blast radius and cutting time to recovery. It complements GitOps reconciliation rather than replacing it, and the rollout policy itself can live in Git.

Why this answer

Limiting blast radius means a defective change should affect as little as possible before it is detected. Progressive delivery with canary or blue-green strategies and automated health gates achieves exactly that: the new version serves a small slice first and is promoted only on success, with automatic rollback on failure. Reconciliation interval tuning, broad production access, and removing review do not constrain the spread or detection of a bad change.

Exam trap

The trap here is equating faster or looser delivery mechanics, such as shorter merge paths or more production access, with improved resilience.

Practice this question →
34
MCQmedium

A security auditor asks how your team handles secret management in a GitOps environment without exposing sensitive credentials in the Git repository. What is the standard GitOps practice for this requirement?

A.Use a tool like Bitnami Sealed Secrets to encrypt secrets that can be decrypted only by the cluster controller.
B.Create a separate private repository for secrets and clone it during the CI/CD pipeline execution.
C.Use Git LFS to encrypt the secret files before pushing them to the remote repository.
D.Store secrets in the repository as Base64 encoded environment variables.
AnswerA

Sealed Secrets encrypts each secret with a public key so only the in-cluster controller holding the private key can decrypt it. The ciphertext is safe to commit, satisfying the requirement to keep credentials out of plaintext in the Git repository.

Why this answer

Sealed Secrets uses asymmetric encryption: the controller in the cluster holds a private key, and developers encrypt secrets with the corresponding public key using kubeseal, producing a SealedSecret CRD that is safe to commit to Git. Only the in-cluster controller can decrypt it into a regular Secret, so credentials never appear in plaintext in the repository. This is the standard GitOps-compatible secret management pattern.

Exam trap

CGOA often tests the misconception that Base64 encoding or a private repo is sufficient to protect secrets, when only encryption with an in-cluster decryption key (Sealed Secrets, SOPS, External Secrets) satisfies GitOps security requirements.

How to eliminate wrong answers

Option B is wrong because a separate private repo still stores plaintext secrets and requires cloning credentials into CI, which expands the attack surface and is not GitOps-native — the CD controller would need access to a second repo. Option C is wrong because Git LFS stores large files, not encrypted secrets; LFS does not encrypt content, so secrets would still be plaintext in the LFS store. Option D is wrong because Base64 is encoding, not encryption — anyone with repo read access can trivially decode the secrets, which is a well-known anti-pattern.

Practice this question →
35
MCQeasy

In the context of a CI/CD pipeline, where does the 'GitOps' bridge typically occur?

A.When the operator triggers the build.
B.When the developer logs into the cluster.
C.When the CI pipeline updates the manifest repository with the new image tag.
D.When the Git repo is deleted.
AnswerC

The bridge occurs when CI finishes building and pushes the updated image tag into the manifest repository. That commit is the handover point: CI stops, and the GitOps operator takes over by reconciling the cluster to the newly declared desired state.

Why this answer

The GitOps bridge in a CI/CD pipeline occurs when the CI pipeline completes building and testing, then updates the manifest repository (e.g., a Git repo containing Kubernetes YAML) with the new image tag. This triggers the GitOps operator to reconcile the cluster to the new desired state.

Exam trap

CGOA often tests the exact point where CI hands off to GitOps, and candidates may incorrectly think the operator triggers the build or that the bridge is at cluster login.

How to eliminate wrong answers

Option A is wrong because the operator does not trigger the build; the CI pipeline is triggered by code commits or other events. Option B is wrong because developer login to the cluster is unrelated to the GitOps bridge. Option D is wrong because deleting the Git repo would break the GitOps process, not bridge it.

Practice this question →
36
Multi-Selectmedium

A team is designing a GitOps workflow and wants to enforce policy and compliance before changes reach production clusters. Which two practices fit a GitOps-aligned governance model? (Choose two.)

Select 2 answers
A.Validate manifests with policy-as-code in CI so violations block the pull request before merge.
B.Store policy definitions only in the operator's configuration file on the cluster host so they cannot be changed by developers.
C.Require engineers to request a firewall exception each time the operator syncs a new manifest to the cluster.
D.Allow any engineer to disable policy checks temporarily by adding a skip label to a manifest.
E.Run policy checks as admission controllers in the cluster so non-compliant resources are rejected at apply time.
AnswersA, E

Policy-as-code checks in CI evaluate proposed manifests against organizational rules and fail the build, preventing non-compliant configuration from ever being merged into the source of truth. This gives fast feedback to authors and keeps the repository clean. Because it runs before merge, it shifts governance left, and pairing it with runtime enforcement covers both authoring mistakes and drift, making it a core GitOps-aligned control.

Why this answer

Governance in GitOps is strongest when it operates at two layers: policy-as-code in CI blocks non-compliant manifests before they are merged, keeping the source of truth clean, and admission controllers in the cluster reject violations at apply time, catching anything that bypasses review or arrives as drift. Together they enforce rules on content rather than on the mechanics of syncing. Per-sync firewall exceptions, host-local policy files, and self-service skip labels all weaken or bypass enforcement.

Exam trap

The trap here is confusing operational approval of sync operations with policy enforcement over the content of the resources being reconciled.

Practice this question →
37
MCQeasy

What is the primary role of the GitOps operator during the reconciliation phase?

A.Reporting the number of users connected to the cluster.
B.Deleting the Git repository to save space.
C.Continuously checking if the cluster matches the desired state in Git.
D.Compiling the application source code.
AnswerC

During reconciliation the operator compares live cluster objects against the desired manifests stored in Git, then applies or prunes to close any gap. This continuous loop satisfies the stem's requirement of continuously checking whether the cluster matches the desired state in Git.

Why this answer

The GitOps operator's core responsibility during reconciliation is to continuously compare the actual state of the cluster with the desired state declared in Git. If any drift is detected, the operator automatically applies changes to bring the cluster back into alignment. This closed-loop process ensures that Git remains the single source of truth for declarative infrastructure and applications.

Exam trap

CGOA often tests the misconception that the GitOps operator performs CI tasks like compiling code or managing user access, when its primary role is strictly the continuous reconciliation of cluster state with Git.

How to eliminate wrong answers

Option A is wrong because reporting user connections is a monitoring or observability function, not part of the GitOps reconciliation loop; GitOps operators do not track user sessions. Option B is wrong because deleting the Git repository would destroy the desired state, directly contradicting the GitOps principle that Git is the immutable source of truth. Option D is wrong because compiling source code is a CI (Continuous Integration) task typically handled by build pipelines, not by the GitOps operator during reconciliation; the operator deals with deploying pre-built artifacts or manifests.

Practice this question →
38
MCQmedium

When configuring a GitOps pipeline, what should be done to manage sensitive data like API keys?

A.Store them in base64 encoded format in plain Git.
B.Leave them out of Git and manually inject them via kubectl.
C.Upload them to the cluster via the cloud provider's console.
D.Use a tool like Sealed Secrets to encrypt them before committing to Git.
AnswerD

Sealed Secrets encrypts values with a cluster-held private key, so the ciphertext is safe to commit to Git while only the in-cluster controller can decrypt it. This satisfies the constraint of keeping secrets out of plaintext in the repository.

Why this answer

Sealed Secrets is a Kubernetes controller and tool that allows you to encrypt secrets into a 'SealedSecret' resource that is safe to store in a Git repository. The SealedSecret can only be decrypted by the controller running in the target cluster, ensuring that sensitive data is not exposed in plain text. This aligns with GitOps principles by keeping all configuration, including secrets, version-controlled and declarative.

Exam trap

The trap here is assuming that base64 encoding provides security, or that manual injection is acceptable in GitOps, when in fact GitOps requires all configuration to be declarative and version-controlled, necessitating encryption tools like Sealed Secrets.

How to eliminate wrong answers

Option A is wrong because base64 encoding is not encryption; it is easily decoded and provides no security, exposing secrets in plain text. Option B is wrong because manually injecting secrets via kubectl breaks the GitOps declarative model and introduces manual steps that are error-prone and not auditable. Option C is wrong because uploading secrets via the cloud provider's console is a manual process that bypasses Git and does not integrate with GitOps workflows, leading to configuration drift.

Practice this question →
39
MCQeasy

A team is transitioning from traditional imperative scripts to declarative Configuration as Code. Which approach best satisfies the GitOps principle of using a desired state definition?

A.Using bash scripts triggered by a Jenkins build job to update environment variables.
B.Directly editing deployments via the 'kubectl edit' command.
C.Storing Kubernetes YAML manifests in a Git repository and using an operator to synchronize them.
D.Using an Ansible playbook to perform one-off configuration changes on existing servers.
AnswerC

Storing Kubernetes YAML manifests in Git and letting an operator synchronise them satisfies the desired-state principle directly: Git holds the declarative specification, and the operator continuously reconciles cluster resources to match it, replacing imperative scripts with automated convergence.

Why this answer

Storing Kubernetes YAML manifests in a Git repository and using an operator to synchronize them is the declarative GitOps approach. The YAML files define the desired state, and the operator continuously reconciles the cluster to match that state. This satisfies the principle of using a desired state definition because the state is versioned, immutable, and declarative.

Exam trap

CGOA often tests the difference between declarative desired state stored in Git and imperative scripts or direct edits, trapping candidates who think any automation tool qualifies as GitOps.

How to eliminate wrong answers

Option A is wrong because bash scripts triggered by Jenkins are imperative and not stored as declarative desired state; they execute commands rather than define a target state. Option B is wrong because kubectl edit directly modifies live state imperatively, bypassing Git and violating GitOps principles. Option D is wrong because Ansible playbooks for one-off changes are imperative and not continuously reconciled; they do not provide a declarative desired state stored in Git.

Practice this question →
40
Multi-Selectmedium

Which TWO of the following are common pitfalls when integrating DevSecOps into a GitOps pipeline?

Select 2 answers
A.Using multiple branches in Git.
B.Skipping vulnerability scans for Kubernetes manifests.
C.Setting up an automated reconciliation operator.
D.Storing unencrypted secrets directly in the Git repository.
E.Automating the deployment of code changes.
AnswersB, D

Skipping vulnerability scans for Kubernetes manifests leaves image references, privileged settings and misconfigurations unchecked before deployment. Because GitOps automatically reconciles whatever Git declares, unscanned manifests propagate straight to clusters, defeating the DevSecOps goal of catching flaws earlier in the pipeline.

Why this answer

Option B is correct because Kubernetes manifests (YAML) can embed insecure configurations such as privileged containers, hostPath mounts, or images with known CVEs, and if the GitOps pipeline only validates application code but never scans the manifests, these misconfigurations reach the cluster unchecked. Option D is correct because Git stores full history, so committing plaintext secrets (passwords, tokens, kubeconfigs) exposes them to anyone with repo read access and they persist even after deletion unless history is rewritten; secrets should instead be managed via Sealed Secrets, External Secrets Operator, or a vault. Option A is not a DevSecOps pitfall per se — multiple branches are a normal Git workflow (though long-lived branches can cause drift, that is a GitOps hygiene issue, not a security pitfall).

Option C is not a pitfall but a core GitOps practice, since an automated reconciliation operator (e.g., Argo CD or Flux) is what enforces the desired state. Option E is also not a pitfall — automating deployment of code changes is the fundamental purpose of a GitOps pipeline.

Exam trap

CGOA often tests whether candidates confuse normal GitOps practices (branching, reconciliation, automation) with actual security pitfalls — the trap is picking a benign practice as a 'pitfall' because it sounds complex.

Practice this question →
41
MCQmedium

Which practice represents the 'DevSecOps' aspect in a GitOps pipeline?

A.Conducting quarterly penetration tests.
B.Enforcing policy constraints via OPA/Gatekeeper that validate manifests against security rules.
C.Requiring a manual sign-off by a security officer for every deployment.
D.Storing secrets in plain text in the Git repository.
AnswerB

OPA/Gatekeeper enforces policy-as-code, rejecting manifests that breach security rules before they reach the cluster. Embedding these checks in the pipeline applies the DevSecOps principle of shifting security left, validating artefacts automatically rather than auditing after deployment.

Why this answer

Enforcing policy constraints via OPA/Gatekeeper that validate manifests against security rules is correct because it embeds automated, policy-as-code security checks directly into the GitOps reconciliation loop. In a GitOps pipeline, the Git repository is the source of truth and Argo CD or Flux continuously syncs cluster state to it; Gatekeeper's admission webhook intercepts manifest creation/updates and rejects any resource that violates OPA Rego policies. This makes security a continuous, version-controlled, and automated part of every deployment, which is the essence of DevSecOps—shifting security left into the development and operations workflow rather than treating it as a separate gate.

Exam trap

CGOA often tests the misconception that any security-related activity (like penetration testing or manual approvals) qualifies as DevSecOps, when the key is automated, policy-as-code enforcement integrated into the GitOps pipeline.

How to eliminate wrong answers

Option A is wrong because quarterly penetration tests are periodic, manual, and external to the deployment pipeline; they do not enforce security continuously or automatically on every manifest change, so they fail to integrate security into the GitOps reconciliation loop. Option C is wrong because requiring a manual sign-off by a security officer for every deployment reintroduces a human bottleneck that contradicts GitOps principles of automated, declarative, and continuous delivery; it is a traditional gate, not DevSecOps automation. Option D is wrong because storing secrets in plain text in the Git repository is a severe security anti-pattern that violates confidentiality and compliance; GitOps secrets should be managed with tools like Sealed Secrets, SOPS, or external secret operators, never committed in plain text.

Practice this question →
42
MCQmedium

Your organization wants to implement DevSecOps by integrating security scanning into a GitOps pipeline. Where should the vulnerability scan happen to prevent insecure configurations from ever reaching the cluster?

A.Only when an auditor requests a security report.
B.By running an automated script to delete pods that fail a security check.
C.During the CI phase, scanning the Kubernetes manifests for security misconfigurations before merging.
D.As a post-deployment check using a Kubernetes admission controller.
AnswerC

Scanning manifests during CI catches misconfigurations at the earliest gate, before merge, so insecure YAML never enters the Git repository that Argo CD reconciles. This satisfies the stem's constraint of preventing insecure configurations from reaching the cluster, since GitOps treats Git as the sole source of truth for cluster state.

Why this answer

To prevent insecure configurations from reaching the cluster, scanning must occur early in the CI phase, ideally on the Kubernetes manifests before they are merged into the Git repository. This shift-left approach catches misconfigurations before deployment, aligning with DevSecOps principles.

Exam trap

CGOA often tests the difference between preventive (shift-left) and reactive (post-deployment) security measures, and candidates may incorrectly choose admission controllers as the primary prevention method.

How to eliminate wrong answers

Option A is wrong because scanning only on auditor request is reactive and does not prevent insecure configurations from being deployed. Option B is wrong because deleting pods after deployment is a remediation step, not prevention, and can cause service disruptions. Option D is wrong because a post-deployment admission controller check occurs after the manifests have already reached the cluster, which is too late to prevent them from being applied.

Practice this question →
43
MCQhard

You are managing a global cluster setup with GitOps. How do you handle configuration that must be identical across all clusters while allowing for regional variations?

A.Only having one cluster.
B.Using a base-overlay structure where the base contains common settings and overlays contain regional variations.
C.Duplicating the configuration for every cluster.
D.Using global variables in a shell script to modify manifests.
AnswerB

A base-overlay structure keeps shared settings in one base while overlays patch only regional differences, avoiding duplication across clusters. This directly satisfies the constraint of identical global configuration with permitted regional variation, and remains declarative and reviewable in Git.

Why this answer

A base-overlay structure (as implemented by Kustomize) lets you define shared configuration once in a base directory and layer cluster- or region-specific patches in overlays, so identical settings stay DRY while regional variations are expressed as targeted overrides. This is the canonical GitOps pattern for multi-cluster fleets because it keeps a single source of truth for common config and isolates divergence to small, reviewable overlay files.

Exam trap

CGOA often tests whether candidates understand that GitOps favours declarative, DRY composition (base + overlay) over imperative templating or duplication — the trap is picking shell-script variables or per-cluster copies as 'simpler' solutions.

How to eliminate wrong answers

Option A is wrong because collapsing to a single cluster eliminates the multi-cluster problem rather than solving it, and defeats the availability and latency goals of a global deployment. Option C is wrong because duplicating configuration per cluster creates drift risk, multiplies maintenance, and violates DRY — a change to a common setting must be replicated N times and any missed copy becomes silent drift. Option D is wrong because shell-script global variables are imperative, untracked in Git, and non-declarative, breaking the GitOps principle that Git is the sole source of truth and that changes are auditable and reversible.

Practice this question →
44
MCQmedium

A team wants to detect when someone manually edits a live resource so that the cluster diverges from Git. Their operator reconciles every five minutes. What is the most accurate statement about detection and remediation in this setup?

A.The manual edit is undetectable until the next reconciliation, at which point the operator restores the Git-defined state.
B.The manual edit is instantly reverted because the API server rejects any write that did not originate from the operator.
C.The manual edit is recorded in Git automatically by the operator so the repository reflects the live cluster.
D.The manual edit becomes the new desired state because the operator treats the most recent write as authoritative.
AnswerA

With periodic reconciliation, the operator compares desired and observed state on its interval, so a manual edit can persist undetected until the next cycle, after which the operator reapplies the Git-defined configuration and reverts the change. This is the expected behavior of a reconciling controller and explains both the detection delay and the automatic remediation, making the statement accurate for a five-minute interval.

Why this answer

A reconciling operator compares desired state from Git with observed state on its reconciliation interval. A manual edit therefore survives until the next cycle, when the operator detects the difference and reapplies the Git-defined configuration, reverting the change. The API server does not police write origins, the newest write does not become desired state, and operators do not push live changes back into Git, so the periodic-detection-then-revert behavior is the accurate description.

Exam trap

The trap here is assuming reconciliation is instantaneous or that the control plane itself prevents changes originating outside the operator.

Practice this question →
45
MCQeasy

In a GitOps environment, what is the main purpose of maintaining Infrastructure as Code?

A.To avoid using cloud provider dashboards.
B.To generate cost reports for the finance department.
C.To ensure that infrastructure can be defined, tracked, and automatically reconciled from Git.
D.To allow developers to log into servers and make changes.
AnswerC

Defining infrastructure declaratively in Git lets a controller continuously compare live state against the committed desired state and automatically reconcile any drift, satisfying GitOps' requirement that Git be the single source of truth. This delivers versioned, auditable, repeatable infrastructure changes without manual intervention.

Why this answer

In a GitOps environment, Infrastructure as Code exists so that infrastructure is declared in version-controlled files, tracked through Git history, and automatically reconciled by a controller to match the declared state. This makes infrastructure reproducible, auditable, and self-healing, which is the foundation of the GitOps operating model.

Exam trap

CGOA often tests whether candidates confuse IaC's purpose (declarative, tracked, reconciled state) with incidental benefits (cost reports, avoiding dashboards) — the trap is picking a plausible-sounding side effect over the core GitOps principle.

How to eliminate wrong answers

Option A is wrong because avoiding cloud dashboards is a side effect, not the purpose — IaC is about declarative, versioned state, not about which UI you use; dashboards can still be used for read-only visibility. Option B is wrong because cost reporting is a possible downstream benefit of tagging and visibility, not the main purpose of IaC, and IaC alone does not produce cost reports. Option D is wrong because allowing developers to log into servers and make changes is the opposite of GitOps — it reintroduces snowflake servers, bypasses Git as the source of truth, and destroys auditability and reproducibility.

Practice this question →
46
MCQmedium

In a GitOps environment, what is the best strategy for managing external dependencies (like Helm charts)?

A.Pinning the version of the Helm chart in your Git repository.
B.Always pulling the latest version from the remote Helm repository.
C.Ignoring the chart version and hoping it stays compatible.
D.Manually downloading the chart to every node.
AnswerA

Pinning the chart version in Git makes the deployed dependency immutable and declarative, so the GitOps controller reconciles to an exact, reproducible revision. Floating versions would let upstream changes drift into the cluster without a commit, breaking Git as the source of truth.

Why this answer

Pinning the Helm chart version in Git ensures the exact chart revision is declared as code, so the GitOps operator reconciles a deterministic, reproducible state. This makes deployments idempotent, enables rollback by reverting the Git commit, and prevents an upstream chart maintainer from silently changing behaviour. Version pinning is the GitOps equivalent of locking dependencies in a package manager.

Exam trap

CGOA often tests the misconception that 'latest' is acceptable in GitOps — candidates confuse convenience with determinism and forget that GitOps demands immutable, reproducible declarations.

How to eliminate wrong answers

Option B is wrong because always pulling the latest chart from the remote repository introduces non-determinism — the same Git commit could deploy different resources over time, breaking reproducibility and auditability. Option C is wrong because ignoring chart versions is not a strategy at all; it invites silent breaking changes and violates the declarative, version-controlled principle. Option D is wrong because manually downloading charts to every node is an imperative, node-level anti-pattern that bypasses Git, cannot be reconciled, and does not scale across a cluster fleet.

Practice this question →
47
MCQmedium

When mapping traditional CI/CD to GitOps, which component from the traditional world is often 'decommissioned' or replaced?

A.The container registry.
B.The build tool (e.g., Maven/npm).
C.The Git version control system.
D.The imperative CD deployment scripts (e.g., shell scripts that run 'kubectl apply').
AnswerD

Imperative scripts running kubectl apply are replaced because GitOps agents continuously reconcile the cluster to the declared Git state, making one-off push commands redundant. The pipeline no longer needs to execute deployment steps itself, so these scripts are decommissioned.

Why this answer

In GitOps, the CD mechanism shifts from imperative push-based scripts (e.g., 'kubectl apply' in a Jenkins job) to a declarative pull-based controller (Flux/Argo CD) that continuously reconciles cluster state with Git. The imperative CD deployment scripts are therefore decommissioned because the GitOps operator replaces their role entirely. The build tool, container registry, and Git itself remain essential parts of the pipeline.

Exam trap

CGOA often tests the misconception that GitOps replaces Git or the container registry, when in fact it replaces the imperative CD push mechanism with a declarative pull-based reconciler.

How to eliminate wrong answers

Option A is wrong because the container registry is still required in GitOps to store and serve container images referenced by manifests. Option B is wrong because build tools like Maven/npm continue to run in the CI phase to produce artifacts; GitOps only replaces the CD/deployment mechanism. Option C is wrong because Git is the foundational source of truth in GitOps — it is the one component that becomes more central, not decommissioned.

Practice this question →
48
Multi-Selecthard

Which THREE strategies are effective for managing configuration at scale in a GitOps environment?

Select 3 answers
A.Copying the entire deployment configuration for every single environment.
B.Organizing manifests into a hierarchical directory structure.
C.Using Kustomize to layer common configuration with environment-specific overrides.
D.Using Helm charts to parameterize deployments.
E.Storing all configurations in a single root-level file.
AnswersB, C, D

A hierarchical directory structure groups manifests by cluster, environment or team, so ownership and scope stay clear as repositories grow. This directly addresses the scale constraint by keeping navigation, review and access control manageable rather than flattening thousands of files into one directory.

Why this answer

Option B is correct because organizing manifests into a hierarchical directory structure (e.g., base/ and overlays/ per environment) lets GitOps tools like Argo CD or Flux scope and reconcile each environment independently, avoiding duplication and enabling clear ownership. Option C is correct because Kustomize uses a base plus overlay model with kustomization.yaml files to apply environment-specific patches (replicas, image tags, resource limits) without copying whole manifests, which is a standard GitOps pattern. Option D is correct because Helm charts parameterize deployments through values.yaml and templating, so one chart can render many environment-specific releases, reducing drift and duplication at scale.

Option A is not appropriate because copying the entire configuration per environment creates massive duplication and drift, making updates error-prone. Option E is not appropriate because a single root-level file does not scale, creates merge conflicts, and prevents per-environment separation of concerns.

Exam trap

CGOA often tests the misconception that duplicating configurations per environment is acceptable for isolation, but the exam expects recognition that scalable GitOps relies on reusable, parameterized, and layered configurations to avoid drift and maintenance nightmares.

Practice this question →
49
MCQhard

How does the GitOps pattern simplify the audit process for a regulatory environment?

A.It provides a clear audit trail in Git by linking every state change to a commit and a user.
B.It moves all audit logs to the cluster memory.
C.It requires manual documentation of every change.
D.It removes the need for logs.
AnswerA

Git records every desired-state change as a commit tied to an author, giving auditors an immutable, timestamped history of who changed what and when. This declarative version control replaces manual change logs, satisfying regulatory traceability requirements.

Why this answer

GitOps simplifies audits because every change to the system is made via a Git commit, which records who made the change, when, and what exactly changed. This creates an immutable, traceable audit trail that can be reviewed and verified, satisfying regulatory requirements for change control and accountability.

Exam trap

CGOA often tests the auditability benefit of GitOps; candidates may think GitOps eliminates logging or requires manual documentation, missing the automated traceability.

How to eliminate wrong answers

Option B is wrong because moving audit logs to cluster memory is not a GitOps feature and would be volatile and insecure. Option C is wrong because GitOps reduces manual documentation by automating the capture of changes in Git history. Option D is wrong because GitOps does not remove the need for logs; it complements logging by providing a declarative change history.

Practice this question →
50
MCQmedium

When mapping a traditional CI/CD pipeline to GitOps, what is the primary role of the CD tool?

A.Reconciling the running state of the cluster with the declarative state defined in Git.
B.Pushing binary artifacts to a server via SSH.
C.Pushing images to a container registry after a build.
D.Generating test reports for the QA team.
AnswerA

In GitOps, the CD tool no longer pushes changes; it continuously reconciles cluster state against the declarative manifests committed in Git. This pull-based reconciliation satisfies the pipeline's deployment stage, replacing imperative push commands with drift correction.

Why this answer

In GitOps, the CD tool (e.g., Argo CD or Flux) acts as a reconciliation controller that continuously compares the desired state declared in Git against the live cluster state and applies any drift corrections. It does not build or push artifacts — that is the CI system's job. The CD tool's core function is to pull the declarative manifests from Git and ensure the cluster matches them.

Exam trap

CGOA often tests the misconception that the CD tool builds or pushes artifacts like a traditional Jenkins pipeline, when in GitOps the CD tool only reconciles declarative state from Git.

How to eliminate wrong answers

Option B is wrong because pushing binary artifacts over SSH describes traditional push-based deployment (e.g., Ansible or a deploy script), which is the opposite of GitOps's pull-based reconciliation model. Option C is wrong because pushing images to a registry is a CI/build responsibility, not the CD tool's role — the CD tool consumes image references already declared in Git. Option D is wrong because generating test reports is a CI/QA concern and has nothing to do with the declarative reconciliation loop that defines GitOps CD.

Practice this question →
51
Multi-Selectmedium

Which THREE items should be included in your Git repository for a standard GitOps setup?

Select 3 answers
A.Policy-as-Code files (e.g., OPA policies).
B.Templating definitions (Helm charts/Kustomize bases).
C.Application source code files.
D.Kubernetes manifest files (YAML).
E.The private keys for the production cluster.
AnswersA, B, D

Policy-as-Code files belong in the repository because GitOps treats Git as the single source of truth for desired state. Storing OPA policies there lets Flux or ArgoCD reconcile admission and compliance rules alongside workloads, satisfying the requirement that all declarative configuration be version-controlled and auditable.

Why this answer

In a standard GitOps setup, the Git repository serves as the single source of truth for the desired state of the system, so it must contain the declarative artifacts that define that state. Option A is correct because Policy-as-Code files such as OPA (Open Policy Agent) policies are declarative guardrails that should be version-controlled and reconciled alongside the rest of the desired state. Option B is correct because templating definitions like Helm charts and Kustomize bases are the reusable, declarative building blocks used to render Kubernetes manifests, and they belong in Git so changes are auditable and reproducible.

Option D is correct because Kubernetes manifest files (YAML) are the declarative descriptions of the workloads and resources that GitOps tools such as Argo CD or Flux continuously reconcile against the cluster. Option C is not required for the GitOps repository itself, since application source code is typically built into container images by a CI pipeline and stored in a separate code repository, with only the resulting image reference placed in the GitOps repo. Option E is never included, because committing private keys for the production cluster into Git would expose credentials and violate security best practices; secrets should be managed with a secrets manager or sealed-secrets mechanism instead.

Exam trap

CGOA often tests the misconception that application source code belongs in the GitOps repository, confusing continuous integration with continuous deployment, or that secrets can be safely stored in Git if encrypted.

Practice this question →
52
Multi-Selecteasy

Which TWO of the following best describe the benefits of adopting GitOps?

Select 2 answers
A.Better auditability through a full history of changes in Git.
B.Improved consistency by ensuring the cluster matches the Git state.
C.Higher speed because testing is bypassed.
D.Increased dependence on manual operator intervention.
E.The ability to run without any container registry.
AnswersA, B

Every commit to the Git repository forms an immutable, timestamped record of who changed what and when. This commit history satisfies the auditability benefit, since the cluster's desired state is traceable directly through Git rather than through opaque pipeline logs.

Why this answer

Option A is correct because GitOps stores all desired-state manifests in Git, so every change is a versioned commit with author, timestamp, and diff, giving a complete, immutable audit trail of who changed what and when. Option B is correct because GitOps controllers such as Argo CD or Flux continuously reconcile the live cluster against the declarative state in Git, detecting and correcting drift so the cluster converges on the committed desired state. Option C is wrong because GitOps does not bypass testing; CI pipelines still run tests and validation before changes are merged and synced.

Option D is wrong because GitOps reduces manual operator intervention through automated reconciliation rather than increasing dependence on it. Option E is wrong because GitOps still relies on container images pulled from a registry; Git holds the manifests, not the image layers.

Exam trap

CGOA often tests the misconception that GitOps bypasses testing or eliminates the need for container registries, when in fact it enhances auditability and consistency while still requiring CI pipelines and image registries.

Practice this question →
53
Multi-Selecthard

Which THREE of these practices are essential to successfully transition from traditional CI/CD to GitOps?

Select 3 answers
A.Maintaining a manual 'deployment' document in a wiki.
B.Replacing imperative 'kubectl' commands with declarative manifest files.
C.Establishing Git as the sole source of truth for the environment.
D.Implementing an automated reconciliation process that pulls from Git.
E.Increasing the number of manual approvals in the CI pipeline.
AnswersB, C, D

Declarative manifests stored in Git let a controller continuously reconcile cluster state against the desired configuration, rather than executing one-off imperative commands. This satisfies GitOps's core requirement that Git be the single source of truth, enabling automated drift detection and rollback without manual `kubectl` intervention.

Why this answer

Option B is correct because GitOps requires the desired state to be expressed declaratively in manifest files (YAML) rather than through imperative commands like 'kubectl apply' or 'kubectl edit', so the cluster state can be versioned and reproduced. Option C is correct because Git must serve as the single source of truth, meaning all environment and application configuration lives in Git repositories and any change is made via commits and pull requests, not directly on the cluster. Option D is correct because a GitOps agent (e.g., Argo CD or Flux) must continuously reconcile the live cluster state with the desired state stored in Git, typically using a pull-based model that detects drift and automatically corrects it.

Option A is not correct because a manual deployment document in a wiki is not version-controlled, not machine-readable, and cannot drive automated reconciliation, which contradicts GitOps principles. Option E is not correct because adding manual approvals increases friction and human intervention, whereas GitOps emphasizes automated, auditable, and repeatable delivery driven by Git commits and CI checks.

Exam trap

CGOA often tests the misconception that more manual approvals or wiki documentation improve GitOps — in reality, GitOps reduces manual gates and treats Git itself as the documentation and approval mechanism.

Practice this question →
54
MCQhard

You are implementing a multi-environment strategy. Which Git branching strategy best supports GitOps?

A.Deleting the Git repository after each deployment to prevent tampering.
B.Using a single 'main' branch that is pushed to all environments simultaneously.
C.Using dedicated directories for each environment within a single repository.
D.Creating a new repository for every single deployment.
AnswerC

Dedicated directories per environment in one repository keep each environment's manifests isolated while sharing a common structure. Promotion becomes a pull request between directories, giving clear diffs and audit trails without the merge complexity of long-lived branches.

Why this answer

In GitOps, the desired state of each environment is stored declaratively in Git, and a controller (e.g., Argo CD or Flux) continuously reconciles the live state to match it. Using dedicated directories per environment within a single repository (e.g., /envs/dev, /envs/staging, /envs/prod) allows each environment to have its own manifests and configuration while sharing common base resources via Kustomize or Helm. This structure supports promotion workflows (e.g., merging changes from dev to staging to prod) and provides clear separation without the overhead of multiple repositories.

It also aligns with the principle of a single source of truth for all environments, making it easier to audit and manage drift.

Exam trap

CGOA often tests the misconception that GitOps requires separate repositories per environment, when in fact a single repository with dedicated directories is the recommended pattern for multi-environment management.

How to eliminate wrong answers

Option A is wrong because deleting the Git repository after deployment destroys the source of truth and prevents any reconciliation or rollback, which is antithetical to GitOps. Option B is wrong because pushing the same branch to all environments simultaneously eliminates environment-specific configuration and promotion gates, leading to unintended changes in production and breaking isolation. Option D is wrong because creating a new repository for every deployment is operationally unscalable, fragments the desired state, and makes it impossible to manage environment-specific overrides or promote changes systematically.

Practice this question →
55
Multi-Selecthard

Which TWO of the following are valid reasons to maintain a clear separation between the CI pipeline and the GitOps controller?

Select 2 answers
A.The GitOps controller is required to perform binary compilation of source code.
B.GitOps provides a continuous feedback loop and reconciliation that a one-time CI execution cannot offer.
C.The CI pipeline should not have direct write access to the Kubernetes API, limiting the blast radius of a compromised pipeline.
D.Separation allows developers to bypass the Git repository when hotfixing production.
E.The CI pipeline is physically incapable of deploying resources to a cluster.
AnswersB, C

The controller continuously reconciles live cluster state against the declared Git desired state, detecting and correcting drift long after the pipeline's one-time build and push has finished. This ongoing feedback loop satisfies the stem's requirement for a distinct reason to separate the two roles.

Why this answer

Option B is correct because a GitOps controller runs a continuous reconciliation loop that constantly compares the desired state in Git with the live cluster state and corrects drift, whereas a CI pipeline executes only once per trigger and then stops, so it cannot provide ongoing convergence or feedback. Option C is correct because keeping the CI pipeline from holding direct write credentials to the Kubernetes API enforces least privilege: if the pipeline is compromised, the attacker cannot directly mutate cluster resources, and all changes must instead flow through Git where they are reviewed, versioned, and auditable, greatly reducing the blast radius. Option A is wrong because binary compilation is a CI/build responsibility, not something the GitOps controller does; the controller only applies declarative manifests.

Option D is wrong because bypassing the Git repository for production hotfixes directly contradicts GitOps principles, which require Git as the single source of truth. Option E is wrong because a CI pipeline is technically capable of deploying to a cluster (e.g., via kubectl or Helm with credentials); the separation is a deliberate security and architectural choice, not a physical limitation.

Exam trap

CGOA often tests the misconception that CI must deploy to the cluster or that GitOps replaces CI — candidates confuse the build/deploy boundary and pick options that violate Git as the source of truth.

Practice this question →

Ready to test yourself?

Try a timed practice session using only Related Practices questions.

Start 20-question session