CNCF / Linux Foundation · Free Practice Questions · Last reviewed May 2026
30 real exam-style questions organised by domain, each with the correct answer highlighted and a plain-English explanation of why it's right — and why the others are wrong.
You are configuring Flux to manage a multi-tenant cluster. You need to ensure that specific namespaces only allow images from an internal registry. Which tool should you use to enforce this at admission time?
ArgoCD Notifications
Kyverno
Kyverno is a Kubernetes-native admission controller that evaluates policies written as Kubernetes resources, so it can block pods in specific namespaces unless their image references match the internal registry. This enforces the constraint at admission time without requiring a separate policy language runtime.
Sealed Secrets
Flux Image Automation Controller
You are using ArgoCD and need to ensure that secret values stored in Git via Sealed Secrets are decrypted only within the target cluster. What component performs the actual decryption of a SealedSecret resource?
GitOps CLI (kubeseal)
Kubernetes API Server
ArgoCD Application controller
Sealed Secrets controller
The Sealed Secrets controller runs inside the target cluster, holds the private key, and decrypts SealedSecret resources into ordinary Secrets. This satisfies the constraint that decryption happens only within the target cluster, since the private key never leaves it and Git stores only ciphertext.
You are using OPA Gatekeeper with GitOps. You want to prevent any deployment that does not have an 'owner' label. Where should this policy be applied to ensure it is enforced for all GitOps-driven changes?
Git pre-receive hook
Flux Source Controller
Validating Admission Webhook
Gatekeeper registers as a Validating Admission Webhook, so the API server evaluates every create and update against the ConstraintTemplate before persistence. This intercepts all GitOps-driven changes at admission time, blocking any Deployment lacking the required owner label regardless of which controller applies it.
ArgoCD AppProject
When migrating from ArgoCD to Flux, you want to replicate the 'Sync Waves' behavior. Which Flux feature provides equivalent control over the order of resource reconciliation?
Post-sync hooks
dependsOn
dependsOn explicitly declares ordering between Flux Kustomization or HelmRelease resources, so a resource reconciles only after its dependencies are healthy. This replicates ArgoCD Sync Waves' staged sequencing, giving equivalent control over reconciliation order during migration.
Sync waves
Reconciliation intervals
Which GitOps tool relies primarily on a pull-based model utilizing the 'Source Controller' and 'Kustomization' custom resources?
Flux
Flux uses the Source Controller to fetch manifests from Git repositories and the Kustomization custom resource to reconcile and apply them, implementing a pull-based GitOps model. Argo CD instead relies on Application resources and its own repo-server component.
ArgoCD
Terraform
Helm
Which of the following is a key advantage of using a 'pull' based GitOps model (like Flux or ArgoCD) over a 'push' based CI/CD pipeline?
Elimination of external cluster credentials in CI
In a pull model the in-cluster agent initiates connections outward to fetch desired state, so the CI system never holds kubeconfig credentials or cluster API access. This eliminates external cluster credentials in CI, removing a significant credential-exposure risk.
Faster build times
Automatic unit testing
No need for Git
Want more Tooling practice?
Practice this domainWhich THREE of the following are core responsibilities of a GitOps operator?
Detecting drift between the cluster state and the Git source
A GitOps operator compares the desired state declared in Git against the live cluster state, identifying any divergence. Detecting drift is a core responsibility because it is the prerequisite step that triggers reconciliation, satisfying the stem's requirement for an operator responsibility.
Writing CI/CD build scripts
Executing manual kubectl commands for developers
Applying necessary changes to reconcile the live state with the desired state
Once drift is detected, the operator applies the changes needed to bring the live cluster back into alignment with the desired state stored in Git. This reconciliation action is a core responsibility, satisfying the stem's requirement for an operator responsibility.
Continuously monitor the declared state in the repository
The operator continuously watches the declared state in the Git repository so that any commit or change is noticed promptly. This ongoing monitoring is a core responsibility because it feeds the reconciliation loop, satisfying the stem's requirement for an operator responsibility.
When setting up Argo CD, which TWO components are essential to define a GitOps workflow?
Kubernetes Node
AppProject
AppProject provides the logical boundary that scopes which repositories, clusters and namespaces an Application may deploy to, satisfying the multi-tenancy and least-privilege constraint. Without it, Applications inherit unrestricted access, so it is essential alongside the Application resource to define a governed GitOps workflow.
Application CRD
The Application CRD is the custom resource that binds a source Git repository path to a destination cluster and namespace, driving Argo CD's reconciliation loop. It is the core declarative object expressing what should be deployed where.
Docker Registry
Jenkins Pipeline
You are troubleshooting a Flux installation. The operator is failing to pull updates from a private GitHub repository. What component is most likely misconfigured?
The Helm chart version
The cluster service account permissions
The Kustomization path
The GitRepository secret
The GitRepository custom resource references a Kubernetes secret holding the credentials or SSH key used to authenticate to the private repository. If that secret is missing, malformed, or lacks valid credentials, the operator cannot pull updates, producing exactly the described failure.
A company transitions from a push-based CI/CD pipeline (using Jenkins) to a pull-based GitOps model (using Flux). What is the primary security architectural change regarding cluster access?
Git is no longer the source of truth
The cluster no longer requires an API server
The operator is now a push-based agent
The CI server no longer requires cluster credentials
In a pull-based GitOps model, the in-cluster operator (Flux) pulls manifests from Git and reconciles them itself, so the external CI server never authenticates to the cluster. Removing those stored cluster credentials eliminates a standing privileged access path that Jenkins previously held.
You are auditing your GitOps deployment strategy. Which TWO of the following statements correctly describe the 'Source of Truth' in a GitOps architecture?
The live cluster state is the ultimate source of truth for all configurations
The declared state in the Git repo must match the observed cluster state
Git holds the declared state, and the reconciliation controller continuously compares it against the observed cluster state, driving convergence. This satisfies the stem's requirement that the two states must match, since drift triggers automatic correction rather than manual intervention.
The Git repository acts as the single source of truth for both infrastructure and applications
The Git repository holds the declarative manifests for infrastructure and applications, making it the single source of truth. An in-cluster agent continuously reconciles live state against this committed state, so any drift is detected and corrected automatically. This satisfies the stem's requirement that one authoritative store governs both layers.
Database backups constitute the primary source of truth
Continuous Integration artifacts are the source of truth
What is the primary benefit of a 'pull' deployment model compared to a 'push' model in GitOps?
Support for non-Kubernetes platforms
Elimination of Kubernetes manifests
Reduced need for inbound firewall access to the cluster
In a pull model the in-cluster agent initiates outbound connections to the Git repository or controller, so no inbound firewall rules or exposed endpoints are needed. This directly satisfies the reduced inbound access requirement compared with push-based deployments.
Faster application builds
Want more Gitops Terminology practice?
Practice this domainWhy is 'Git' considered the 'source of truth' in GitOps?
Because it acts as the single point of record for the desired system state.
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.
Because Git stores all application logs.
Because it is the only tool that supports branching.
Because Git automatically runs the applications.
In a GitOps environment, what is the main purpose of maintaining Infrastructure as Code?
To avoid using cloud provider dashboards.
To generate cost reports for the finance department.
To ensure that infrastructure can be defined, tracked, and automatically reconciled from Git.
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.
To allow developers to log into servers and make changes.
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?
Only when an auditor requests a security report.
By running an automated script to delete pods that fail a security check.
During the CI phase, scanning the Kubernetes manifests for security misconfigurations before merging.
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.
As a post-deployment check using a Kubernetes admission controller.
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?
Use Crossplane to represent infrastructure as Kubernetes objects, managing both IaC and apps via GitOps.
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.
Execute Terraform via a CI job that triggers Argo CD after completion.
Manually trigger Terraform runs before pushing new app manifests to Git.
Embed Terraform binary execution within a K8s deployment container.
When mapping a traditional CI/CD pipeline to GitOps, what is the primary role of the CD tool?
Reconciling the running state of the cluster with the declarative state defined in Git.
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.
Pushing binary artifacts to a server via SSH.
Pushing images to a container registry after a build.
Generating test reports for the QA team.
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?
The container registry is unreachable during a new image rollout.
The Git repository contains syntax errors in the YAML files.
A user performed a manual 'kubectl' command to modify a deployment.
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.
The CI pipeline failed to run tests.
Want more Related Practices practice?
Practice this domainIn a multi-cluster GitOps architecture using Argo CD, how do you manage credentials for a remote cluster that is not the cluster where Argo CD resides?
Modify the global ConfigMap in the Argo CD namespace
Add the cluster URL to the Git repository manifest
Use the argocd cluster add command to store credentials as a secret in the Argo CD namespace
The argocd cluster add command registers the remote cluster with Argo CD and writes its credentials as a Secret in the Argo CD namespace, which is exactly where the controller reads them when deploying to that external cluster.
Manually create a Kubernetes secret in the remote cluster
In a blue-green progressive delivery deployment using Flagger, you notice that the 'primary' service is not receiving traffic even after the analysis successfully completes. What is the most likely cause?
The analysis template lacks the 'weight' parameter
The Flagger controller is in 'paused' mode
The VirtualService or HTTPRoute is not pointing to the primary service
Flagger promotes the canary by rewriting the VirtualService or HTTPRoute backend to reference the primary service once analysis succeeds. If that routing resource still targets the canary or an outdated backend, the primary receives no traffic despite a successful analysis, directly matching the stem's symptom.
The canary resource is missing a 'host' definition
You are deploying applications across multiple clusters using Argo CD. You want to implement a hub-and-spoke model where the central management cluster controls all edge clusters. Which THREE of the following are necessary to correctly configure this pattern?
Install Argo CD control plane components on every edge cluster
Configure the 'server.enable.proxy' flag in the hub cluster
Ensure the service account for Argo CD has cluster-admin permissions on target clusters
Argo CD's management cluster must authenticate to each spoke cluster's API server and create or modify resources there. Cluster-admin permissions on the target clusters grant that authority, enabling the hub to deploy and reconcile applications across all edge clusters.
Define Application projects to restrict cluster access
AppProjects scope which repositories, clusters and namespaces an Application may target, enforcing least privilege in the hub-and-spoke topology. Defining them restricts each spoke's deployments, preventing the central Argo CD instance from applying resources to unauthorised clusters.
Create Argo CD cluster secrets in the management cluster namespace
Argo CD registers external clusters by storing connection details, including the API server URL and credentials, as Kubernetes Secrets labelled for Argo CD in the management cluster namespace. Creating these secrets is what lets the hub target each spoke cluster.
When promoting an application from staging to production using the 'GitOps directory' pattern, what is the most robust way to ensure environment-specific configurations are applied correctly?
Using Kustomize overlays for each environment
Kustomize overlays keep a single base manifest while patching only the values each environment differs on, so staging and production share structure but receive their own replicas, hostnames and resources, satisfying the requirement for correct environment-specific configuration.
Hardcoding environment names inside the main deployment file
Dynamic shell scripting in the CI pipeline
multiple_choice
Copy-pasting YAML files across folders
You are managing a large-scale deployment using the App-of-Apps pattern in Argo CD. Which resource type do you primarily use as the parent application to reference child application manifests?
Application
In App-of-Apps, the parent is itself an Application custom resource whose manifests point to a directory of child Application manifests. Argo CD syncs the parent, which then creates and manages each child, satisfying the stem's requirement for a parent referencing child applications.
SyncPolicy
ArgoCD Project
AppProject
You are implementing progressive delivery with Flagger. You notice that the canary analysis is failing despite the new version being stable. What is the most common reason for this?
The deployment strategy is set to 'Immediate' instead of 'Canary'.
The Prometheus query for success rate is returning no data.
Flagger's canary analysis depends on Prometheus metrics; if the success-rate query returns no data, Flagger treats the metric as failed and aborts the rollout. The stable version is fine, but the query itself is misconfigured or the metric name is wrong.
The Git repository is in read-only mode.
The service mesh sidecar is missing the 'canary' annotation.
Want more Gitops Patterns practice?
Practice this domainWhich TWO of the following are primary benefits of storing immutable state in Git?
Reduction in manual cluster configuration errors
Storing immutable state in Git eliminates manual cluster configuration errors because every change is versioned, peer-reviewed and revertible, rather than applied by hand. Git's commit history provides an auditable record, so drift and fat-fingered edits are caught before reaching production, satisfying the stem's requirement for reduced human error.
Faster deployment of hotfixes directly to production
Automated conversion of Docker images to YAML
Ability to audit all environment changes through commit history
Commit history records every state change with author, timestamp and diff, giving a complete, tamper-evident audit trail of environment modifications. Because Git commits are content-addressed and immutable, earlier entries cannot be silently altered, satisfying the stem's audit requirement directly.
Increased server-side storage capacity
You are implementing a GitOps workflow where the desired state is stored in a private repository. The Argo CD controller requires access to this repository. What is the most secure GitOps-compliant way to provide this access?
Grant the cluster node broad read access to all public repositories.
Use an environment variable in the Argo CD container deployment manifest.
Create a Kubernetes Secret containing the SSH key and reference it in the repository configuration.
Storing the SSH deploy key in a Kubernetes Secret keeps credentials out of the Git repository and manifests, and Argo CD references that Secret in its repository configuration. This satisfies the stem's private-repository access requirement while remaining GitOps-compliant.
Hardcode the credentials in the Application manifest.
In an Argo CD deployment, a developer notices that manual changes made via kubectl are being reverted automatically. What feature is responsible for this behavior?
Git commit hook triggers
Auto-Sync with Self-Heal enabled
Self-heal continuously reconciles live cluster state against the desired state declared in Git, so any drift introduced by kubectl is detected and reverted automatically. Without self-heal, auto-sync alone only applies new Git commits, leaving manual edits in place until the next sync.
Kubernetes admission controllers
Manual refresh button
Your team is using a pull-based GitOps pattern. Which component is responsible for initiating the communication to the Git repository to check for updates?
The developer's local kubectl client.
The agent running inside the Kubernetes cluster.
In pull-based GitOps, the in-cluster agent (such as Flux or Argo CD) polls the Git repository and pulls desired state, so it initiates outbound communication; the repository never pushes to the cluster, satisfying the pull constraint.
The CI/CD pipeline pushes updates to the cluster.
The Git server pushes changes to the cluster webhook.
An organization is migrating to GitOps using Argo CD. During an audit, you notice that manual changes made directly to the Kubernetes cluster via kubectl are being reverted within minutes. Which component of the GitOps pipeline is performing this action?
The cluster ingress controller
The Argo CD API server
The Git webhook listener
The Application Controller
The Application Controller continuously compares live cluster state against the desired state in Git and reconciles drift. When kubectl edits diverge from Git, it detects the OutOfSync difference and reapplies the manifest, reverting the manual change within its polling interval.
In a GitOps environment, an engineer manually deletes a Deployment via 'kubectl'. What should happen next to maintain the desired state?
The controller detects the drift and automatically restores the Deployment.
The GitOps controller continuously compares live cluster state against the Git-declared desired state. Deleting the Deployment creates drift, so the controller's reconciliation loop recreates the missing resource automatically, restoring the declared state without manual intervention.
The controller ignores the change until the next git commit.
The system issues an alert but does not modify the cluster.
The manual deletion is permanently synced to the Git repository.
Want more Gitops Principles practice?
Practice this domainThe CGOA exam is performance-based — there are no multiple-choice questions. It is a hands-on lab exam completed within 90 minutes. You complete practical tasks in a live or simulated environment. Courseiva practice questions cover the underlying concepts.
Hands-on labs and command-line tasks in a live Kubernetes cluster.
The exam covers 5 domains: Tooling, Gitops Terminology, Related Practices, Gitops Patterns, Gitops Principles. Questions are weighted by domain — higher-weight domains appear more on your actual exam.
No. These are original exam-style practice questions written against the official CNCF / Linux Foundation CGOA exam objectives. They are not copied from the real exam. Courseiva focuses on genuine understanding, not memorisation of braindumps.
Courseiva tracks your accuracy per domain and routes you toward weak areas automatically. Free, no account required.