Courseiva

CCNA Tooling Questions

40 questions · Tooling · All types, answers revealed

1
MCQhard

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

A.kubectl get policies
B.kyverno test
C.kubectl describe policy
D.kyverno apply
AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

2
MCQmedium

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

A.The number of times the app has synced
B.The ArgoCD version
C.The specific git hash or branch being tracked
D.The version of the Helm chart
AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

3
MCQmedium

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

A.ArgoCD reverts the change to match the Git state
B.The change is permanently accepted
C.ArgoCD flags the app as 'OutOfSync' but waits for manual intervention
D.The manual change is merged into Git
AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

4
MCQhard

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

A.Post-build variables
B.Overlays
C.Flux Kustomization resource
D.Helm charts
AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

5
Multi-Selectmedium

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

Select 3 answers
A.Git reference (branch/tag)
B.Reconciliation interval
C.Kubernetes node labels
D.Repository URL
E.Database password
AnswersA, B, D

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

Why this answer

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

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

Exam trap

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

6
MCQeasy

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

A.Flux
B.ArgoCD
C.Terraform
D.Helm
AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

7
MCQmedium

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

A.The argocd-application-controller, because it performs the actual Kubernetes API calls to apply resources and cannot connect to the API server.
B.The argocd-server, because it serves the web UI and API and must fetch the manifests on behalf of the controller.
C.The argocd-repo-server, because it is responsible for cloning the Git repository and generating the manifests, and it cannot reach the private repository.
D.The argocd-dex-server, because it provides authentication and the Application may be failing due to an expired token.
AnswerC

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

Why this answer

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

Exam trap

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

8
MCQmedium

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

A.ClusterRoleBinding
B.Sync policies
C.AppProject
D.ApplicationSet
AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

9
Multi-Selectmedium

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

Select 2 answers
A.Sending a kill signal to the controller
B.Clicking 'Sync' in the ArgoCD UI
C.Webhook from Git repository
D.Deleting the Git repository
E.Restarting the API server
AnswersB, C

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

Why this answer

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

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

Exam trap

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

10
Multi-Selectmedium

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

Select 3 answers
A.External Secrets Operator
B.Sealed Secrets
C.Mozilla SOPS
D.Committing raw Kubernetes Secret YAMLs
E.Hardcoding credentials in Dockerfiles
AnswersA, B, C

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

Why this answer

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

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

Exam trap

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

11
MCQhard

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

A.interval: 0
B.reconcile: false
C.suspend: true
D.pause: true
AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

12
MCQmedium

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

A.GitOps CLI (kubeseal)
B.Kubernetes API Server
C.ArgoCD Application controller
D.Sealed Secrets controller
AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

13
Multi-Selecteasy

Which TWO of the following tools allow for GitOps policy enforcement?

Select 2 answers
A.OPA Gatekeeper
B.Helm
C.ArgoCD
D.Flux
E.Kyverno
AnswersA, E

OPA Gatekeeper enforces policies at the Kubernetes admission-control layer, rejecting non-compliant manifests before they reach the cluster. This satisfies GitOps enforcement because the declarative Git source remains the single truth, yet Gatekeeper blocks any drift or policy-violating resource at apply time, independent of the CI pipeline that merged it.

Why this answer

OPA Gatekeeper (A) is correct because it is a Kubernetes admission controller that enforces policies written in Rego, allowing GitOps pipelines to validate and reject non-compliant manifests before they are applied to the cluster. Kyverno (E) is also correct because it provides Kubernetes-native policy enforcement via validating, mutating, and generating admission rules, which integrates with GitOps workflows to ensure only policy-compliant resources are deployed. Helm (B) is a package manager for templating and deploying Kubernetes manifests, not a policy enforcement engine.

ArgoCD (C) and Flux (D) are GitOps continuous delivery tools that sync cluster state with Git, but they do not themselves enforce policy; they rely on tools like Gatekeeper or Kyverno for that purpose.

Exam trap

CGOA often tests the confusion between GitOps delivery tools (ArgoCD, Flux) and policy engines (Gatekeeper, Kyverno), causing candidates to select delivery tools as policy enforcement solutions.

14
Multi-Selecthard

You are using Flux to manage a multi-tenant cluster. You want to enforce that all Kustomizations in a specific namespace can only deploy resources that are allowed by a policy. You have decided to use OPA Gatekeeper. Which two resources are required to define and enforce a policy in Gatekeeper? (Choose two.)

Select 2 answers
A.Constraint
B.Kustomization
C.Policy
D.ConstraintTemplate
E.ConfigMap
AnswersA, D

A Constraint is an instance of a ConstraintTemplate that specifies the scope (e.g., which namespaces or resources) and the parameters. It is the resource that actually enforces the policy. You need both a ConstraintTemplate and a Constraint to define and apply a policy.

Why this answer

In OPA Gatekeeper, a ConstraintTemplate defines the policy logic and schema, while a Constraint is an instance that specifies the scope and parameters. Together, they define and enforce a policy. The other options are either not Gatekeeper resources or serve different purposes.

Exam trap

The trap here is thinking that a Policy resource exists in Gatekeeper, or that a Kustomization can enforce policy logic.

15
MCQhard

You are debugging a flux-system reconciliation loop. You notice the Kustomization is stuck in 'Retrying'. What command shows the current status and reason for the failure?

A.flux get kustomizations
B.flux logs
C.kubectl describe kustomization
D.flux wait
AnswerA

The flux get kustomizations command reports each Kustomization's readiness status and the underlying error message, exposing why reconciliation is retrying. It satisfies the need to inspect current state and failure reason without digging through controller logs.

Why this answer

`flux get kustomizations` is the canonical Flux CLI command that lists every Kustomization with its READY state, STATUS message, and last-applied revision, and when a Kustomization is stuck in 'Retrying' the STATUS column shows the exact error (e.g., a failed apply, a missing dependency, or a source-not-ready condition). It queries the Flux CRDs directly and is the fastest way to see the reconciliation reason without digging into controller logs.

Exam trap

CGOA often tests the difference between Flux-native commands (`flux get`, `flux logs`, `flux reconcile`) and generic kubectl commands — the trap is choosing `kubectl describe` or a non-existent `flux wait` instead of the idiomatic `flux get kustomizations`.

How to eliminate wrong answers

Option B is wrong because `flux logs` streams controller logs across all Flux controllers and is useful for deep debugging, but it does not give a per-Kustomization status summary — you would have to grep and correlate log lines manually. Option C is wrong because `kubectl describe kustomization` is not a valid command: Kustomization is a Flux CRD, and while `kubectl describe kustomization <name>` can work if the CRD is installed, it is not the idiomatic Flux command and does not surface the same concise status/reason view; the exam expects the Flux-native CLI. Option D is wrong because `flux wait` is not a real Flux subcommand — there is no such command in the Flux CLI, so it cannot report status.

16
MCQhard

You have a Git repository that contains multiple Kustomizations. You want Flux to update all of them based on a single trigger. How should you structure the repository?

A.Using one Git repo per application
B.Disabling Kustomize
C.Using a base directory and multiple overlays
D.Combining all manifests into one large file
AnswerC

A base directory holds shared manifests, while overlays reference it and patch per-environment values; a single Flux Kustomization pointed at the overlays path triggers all of them. This satisfies the stem's single-trigger requirement across multiple Kustomizations.

Why this answer

Using a base directory and multiple overlays is the correct approach because Kustomize's base/overlay pattern allows a single Git repository to contain multiple Kustomizations that share common resources. When Flux detects a change in the repository, it can trigger reconciliation for all Kustomizations that reference the same base or overlays, enabling a single trigger to update all of them. This structure promotes DRY principles and simplifies management of multiple environments or variants from one source of truth.

Exam trap

CGOA often tests the misconception that each application or Kustomization requires a separate Git repository, but the exam expects knowledge of Kustomize's base/overlay pattern for efficient multi-Kustomization management from a single repo.

How to eliminate wrong answers

Option A is wrong because using one Git repo per application would require multiple repositories, each with its own trigger, defeating the goal of a single trigger for all Kustomizations. Option B is wrong because disabling Kustomize removes the ability to use Kustomizations altogether, which are the very resources that need to be updated. Option D is wrong because combining all manifests into one large file eliminates the modularity and separation provided by Kustomizations, making it impossible to manage them individually and likely causing conflicts or maintenance issues.

17
MCQmedium

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?

A.Git pre-receive hook
B.Flux Source Controller
C.Validating Admission Webhook
D.ArgoCD AppProject
AnswerC

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.

Why this answer

OPA Gatekeeper enforces policies through a Validating Admission Webhook registered with the Kubernetes API server, so every create/update request — including those from Flux or ArgoCD — is evaluated before persistence. This guarantees the 'owner' label requirement is enforced regardless of how the manifest reaches the cluster.

Exam trap

The trap is assuming GitOps controllers enforce policy — they apply manifests but do not validate them; only an admission webhook like Gatekeeper (or Kyverno) can block non-compliant resources at the API server.

How to eliminate wrong answers

Option A is wrong because a Git pre-receive hook only validates pushes to the Git server; it cannot see cluster state, cannot enforce on resources created outside Git, and is bypassed by direct kubectl applies or by GitOps controllers reconciling already-merged commits. Option B is wrong because the Flux Source Controller only fetches and packages source artifacts from Git/Helm/OCI — it does not evaluate admission policies. Option D is wrong because an ArgoCD AppProject scopes which repos, clusters, and namespaces an Application may target; it is an ArgoCD RBAC/scoping construct, not a policy engine, and it does not apply to Flux or to non-ArgoCD changes.

18
MCQhard

You are using ArgoCD and need to ensure that a Helm chart is rendered correctly with a specific set of values. Where do you specify these values in the ArgoCD Application resource?

A.spec.syncPolicy.values
B.spec.parameters
C.spec.destination.values
D.spec.source.helm.values
AnswerD

Helm values are supplied under spec.source.helm.values in the ArgoCD Application resource, where the chart's value overrides are declared. ArgoCD passes these to the Helm template rendering, ensuring the chart renders with the specific values required.

Why this answer

In an ArgoCD Application resource, Helm values are specified under spec.source.helm.values, which is the field ArgoCD reads when rendering the chart. This allows you to override chart defaults with a specific set of values. The other paths do not exist in the Application CRD.

Exam trap

CGOA often tests the exact path of Helm values in the Application CRD; candidates confuse spec.source.helm.values with non-existent fields like spec.parameters or spec.syncPolicy.values.

How to eliminate wrong answers

Option A is wrong because spec.syncPolicy controls sync behavior such as automated sync, pruning, and self-heal; it has no values field. Option B is wrong because spec.parameters is not a valid field in the Application spec for Helm values; parameters are used in other contexts like Kustomize or plugin configs. Option C is wrong because spec.destination defines the target cluster and namespace, not Helm values.

19
Multi-Selecthard

Which THREE of the following are valid components of the ArgoCD architecture?

Select 3 answers
A.API Server
B.Application Controller
C.Repo Server
D.Source Controller
E.Kustomization Controller
AnswersA, B, C

The API Server is ArgoCD's central gRPC/REST service, handling all UI, CLI and CI/CD interactions. It enforces RBAC, manages application state and delegates Git repository operations to the Repo Server. This satisfies the stem's requirement for a valid architectural component, as it is one of ArgoCD's core services alongside the Application Controller and Redis.

Why this answer

The ArgoCD architecture is composed of three main components: the API Server (A), which exposes the gRPC/REST API used by the Web UI, CLI, and CI systems and handles authentication, RBAC, and application management; the Application Controller (B), which continuously monitors running applications and compares live state against the desired state defined in Git (a Kubernetes controller that performs sync/health assessment); and the Repo Server (C), which maintains a local cache of Git repositories and generates Kubernetes manifests by rendering Helm charts, Kustomize, or plain YAML. Options D (Source Controller) and E (Kustomization Controller) are not ArgoCD components — Source Controller is part of Flux (Flux's source-controller), and Kustomization Controller is also a Flux component (kustomize-controller), so neither belongs to the ArgoCD architecture.

Exam trap

CGOA often tests whether candidates can distinguish ArgoCD's native components from Flux's controllers (source-controller, kustomize-controller, helm-controller), which are commonly mixed into the answer choices as distractors.

20
MCQeasy

Which of these is a primary reason for using Helm charts in a GitOps workflow?

A.Encrypting all traffic
B.Replacing the need for Kubernetes
C.Creating Git commits automatically
D.Templating and packaging complex applications
AnswerD

Helm's chart templating renders parameterised manifests from values files, packaging interdependent Kubernetes resources as one versioned artefact. GitOps stores only declarative state in Git, so this abstraction lets Flux reconcile complex applications without duplicating raw YAML per environment.

Why this answer

Helm charts are used in GitOps workflows primarily for templating and packaging complex applications (D). Helm allows you to define Kubernetes resources as parameterized templates, making it easy to manage and version application configurations in Git. This aligns with GitOps principles where the desired state is stored declaratively in Git and applied automatically.

Exam trap

CGOA often tests the confusion between Helm's role as a package manager and other tools' roles, such as encryption or CI/CD automation, causing candidates to select options that are not primary reasons for using Helm.

How to eliminate wrong answers

Option A is wrong because Helm does not encrypt traffic; encryption is handled by Kubernetes networking, service meshes, or TLS certificates. Option B is wrong because Helm does not replace Kubernetes; it is a package manager that runs on top of Kubernetes. Option C is wrong because Helm does not create Git commits automatically; Git commits are made by developers or CI/CD tools, not by Helm.

21
Multi-Selectmedium

Which THREE of the following actions occur during an ArgoCD sync operation?

Select 3 answers
A.Comparing live state vs desired state
B.Deleting all existing pods
C.Rebuilding the application image
D.Applying updates to the cluster
E.Fetching latest manifests from Git
AnswersA, D, E

ArgoCD continuously reconciles by diffing the desired manifests held in Git against the live resources in the cluster, detecting drift before any change is applied. This comparison is the prerequisite step that determines whether a sync is required and which resources are out of sync.

Why this answer

Option A is correct because an ArgoCD sync begins by comparing the live state of the cluster against the desired state stored in Git (the target revision), which determines what needs to change. Option D is correct because the sync operation then applies those differences to the cluster, using kubectl apply or server-side apply to reconcile resources to the desired manifests. Option E is correct because ArgoCD must fetch the latest manifests from the Git repository at the specified revision before it can render and apply them.

Option B is not correct because ArgoCD performs a rolling or declarative update and does not delete all existing pods as part of a normal sync. Option C is not correct because ArgoCD deploys pre-built manifests and does not build or rebuild container images; image building is handled by CI pipelines.

Exam trap

The trap is confusing CI and CD responsibilities; candidates might think ArgoCD rebuilds images or deletes pods, but those are not part of its sync operation.

22
MCQeasy

What is the purpose of the 'SealedSecrets' custom resource?

A.Backing up Kubernetes secrets
B.Managing cluster-wide RBAC
C.Encrypting traffic between pods
D.Encrypting sensitive data for Git storage
AnswerD

SealedSecrets encrypts sensitive data with a controller-held asymmetric key, producing ciphertext safe to commit to Git. Only the in-cluster controller can decrypt it, so plaintext never enters version control. This directly satisfies the stem's Git-storage constraint, unlike client-side encryption lacking cluster-bound decryption.

Why this answer

SealedSecrets is a Kubernetes controller that encrypts Secret manifests with a cluster-specific public key so the ciphertext can be safely committed to Git. Only the controller in the target cluster, holding the private key, can decrypt the SealedSecret back into a regular Secret. This enables GitOps workflows where secrets live in version control without exposing plaintext.

Exam trap

CGOA often tests confusion between SealedSecrets (encrypting secrets for Git) and general secret management or backup tools, tricking candidates into picking 'backing up secrets' or 'encrypting traffic'.

How to eliminate wrong answers

Option A is wrong because SealedSecrets is not a backup tool; it encrypts secrets for Git storage, and backups are handled by etcd snapshots or Velero. Option B is wrong because cluster-wide RBAC is managed by Kubernetes RBAC objects (Roles, ClusterRoles, Bindings), not by SealedSecrets. Option C is wrong because encrypting pod-to-pod traffic is the domain of a service mesh (Istio/Linkerd mTLS) or network policy with encryption, not SealedSecrets.

23
MCQhard

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?

A.ArgoCD Notifications
B.Kyverno
C.Sealed Secrets
D.Flux Image Automation Controller
AnswerB

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.

Why this answer

Kyverno is a Kubernetes-native policy engine that enforces rules at admission time via a validating (and mutating) admission webhook, making it the correct tool to restrict image registries per namespace. A Kyverno ClusterPolicy or Policy with a validate rule can match pods in specific namespaces and reject any image not sourced from the internal registry.

Exam trap

The trap is assuming GitOps tooling (Flux, ArgoCD) can enforce runtime policy — GitOps controllers apply manifests but do not validate them at admission; only an admission webhook like Kyverno or Gatekeeper can block non-compliant resources.

How to eliminate wrong answers

Option A is wrong because ArgoCD Notifications is an alerting/eventing component for ArgoCD — it sends notifications on sync events and has no admission-time enforcement capability. Option C is wrong because Sealed Secrets is a GitOps secret encryption tool; it has no policy enforcement role. Option D is wrong because the Flux Image Automation Controller updates image tags in Git based on registry scans — it automates image updates but does not enforce admission policies.

24
Multi-Selectmedium

Which TWO of the following are key features of the Flux Kustomization controller?

Select 2 answers
A.Reconciling Kubernetes manifests
B.Direct integration with Jenkins
C.Post-build variable substitution
D.Hosting a private Git server
E.Managing container image build pipelines
AnswersA, C

The Kustomization controller continuously reconciles Kubernetes manifests from a source, applying kustomize build output to the cluster and correcting drift. This satisfies the stem's feature requirement, as reconciliation is the controller's core function, distinct from the GitRepository source controller's fetching role.

Why this answer

Option A is correct because the Flux Kustomization controller's core job is to reconcile Kubernetes manifests from a source (such as a GitRepository or OCIRepository) into the cluster, applying them and continuously correcting drift to match the desired state. Option C is correct because Flux Kustomization supports post-build variable substitution, where placeholders like ${VAR} in the manifests are replaced using values from ConfigMaps/Secrets referenced in the spec.postBuild.substituteFrom field before the resources are applied. The unmarked options do not belong: Flux has no direct Jenkins integration (B), it does not host a private Git server (D) — it only consumes sources via GitRepository/OCIRepository — and it does not manage container image build pipelines (E), which is the role of tools like Tekton or CI systems rather than the Kustomization controller.

Exam trap

CGOA often tests the boundary between CI and GitOps; candidates incorrectly attribute CI tasks like image builds or Jenkins integration to Flux Kustomization.

25
MCQmedium

You are using Flux with a GitRepository source that points to a private Git repository over HTTPS. Flux is failing to fetch the repository with an authentication error. You have created a Kubernetes Secret with the username and password. Which field in the GitRepository spec must reference this Secret?

A.spec.auth
B.spec.credentials
C.spec.sshCredentials
D.spec.secretRef
AnswerD

The spec.secretRef field in a GitRepository is used to reference a Kubernetes Secret containing authentication credentials, such as username and password or a token. This is the correct field to enable Flux to authenticate to a private repository over HTTPS. Without it, Flux cannot access the repository.

Why this answer

In Flux, authentication for GitRepository sources is configured by referencing a Kubernetes Secret in the spec.secretRef field. This Secret must contain the appropriate credentials, such as username and password for HTTPS. The other options are not valid API fields, so they cannot be used to provide credentials.

Exam trap

The trap here is assuming that authentication is configured through a field named auth or credentials, when Flux specifically uses secretRef.

26
Multi-Selecthard

When using Kyverno, which THREE of the following can be used to validate Kubernetes resources?

Select 3 answers
A.SQL queries
B.Bash scripting
C.Conditional logic (if/then)
D.Pattern matching
E.JMESPath expressions
AnswersC, D, E

Conditional if/then logic lets a Kyverno validate rule apply checks only when a condition matches, satisfying the stem's requirement for resource validation. It gates the pattern or deny behaviour on specific field values, so validation targets the relevant resources rather than every request.

Why this answer

Kyverno validates Kubernetes resources through declarative policy rules, and option C (conditional logic (if/then)) is correct because Kyverno supports `if`/`else` conditional blocks within rules to evaluate resource attributes and conditionally apply validation behavior. Option D (pattern matching) is correct because Kyverno's `pattern` and `anyPattern` match blocks perform structural, wildcard-based matching against resource manifests to enforce required fields and values. Option E (JMESPath expressions) is correct because Kyverno uses JMESPath in `preconditions`, `deny` conditions, and variable substitution to query and evaluate fields within the admission request object.

Options A (SQL queries) and B (Bash scripting) are not part of Kyverno's policy language; Kyverno policies are YAML-based and do not execute SQL or shell scripts for validation.

Exam trap

CGOA often tests the misconception that Kyverno supports general-purpose scripting (Bash/SQL), when it actually uses declarative pattern matching, JMESPath, and if/then logic.

27
Multi-Selecthard

When using SOPS with Age, which THREE of the following are true regarding key management?

Select 3 answers
A.Multiple public keys can be added to one SOPS file
B.Private keys must be stored securely in the cluster
C.Age keys require an external KMS
D.Only one person can decrypt the files
E.Public keys are used for encryption
AnswersA, B, E

SOPS encrypts each file's data key with every recipient's public key, so several Age public keys can be listed in one file. Any corresponding private key then decrypts it, satisfying multi-recipient access without sharing secrets.

Why this answer

Option A is correct because SOPS supports encrypting the data key to multiple recipients, so several Age public keys can be listed in the same SOPS file, allowing any corresponding private key holder to decrypt. Option B is correct because the Age private key is the secret that actually decrypts the file, so it must be stored securely (for example, as a Kubernetes Secret with restricted RBAC) to prevent unauthorized decryption. Option E is correct because Age is an asymmetric encryption scheme: the public key is used to encrypt/wrap the data key, while the matching private key is required for decryption.

Option C is incorrect because Age is a standalone, file-based key system and does not require an external KMS such as AWS KMS, GCP KMS, or Azure Key Vault. Option D is incorrect because SOPS with Age supports multiple recipients, so more than one person (or workload) can hold a private key and decrypt the files.

Exam trap

CGOA often tests the misconception that Age requires an external KMS like AWS KMS or Vault — Age is deliberately KMS-free, and candidates who assume otherwise pick option C.

28
MCQmedium

When using OPA Gatekeeper for policy enforcement, what resource is used to define the actual logic of the policy?

A.AdmissionRule
B.GatekeeperConfig
C.PolicyDefinition
D.ConstraintTemplate
AnswerD

ConstraintTemplate defines the Rego logic and the parameters schema that Gatekeeper enforces; the Constraint merely instantiates it with values. This satisfies the stem by identifying the resource holding the actual policy logic rather than the enforcement instance.

Why this answer

In OPA Gatekeeper, a ConstraintTemplate defines the Rego policy logic and the schema of the constraint's parameters. It is a cluster-scoped custom resource that, when created, causes Gatekeeper to generate a new CRD (the constraint kind). You then instantiate that kind as a Constraint to actually enforce the policy on selected resources.

The ConstraintTemplate is where the actual policy logic lives.

Exam trap

CGOA often tests the confusion between ConstraintTemplate (the logic/schema) and Constraint (the instantiation with parameters and match criteria) — candidates pick Constraint when asked where the logic lives.

How to eliminate wrong answers

Option A is wrong because AdmissionRule is not a Gatekeeper resource — Gatekeeper uses ConstraintTemplate and Constraint; AdmissionRule is a generic term that does not map to the Gatekeeper API. Option B is wrong because GatekeeperConfig is a real resource but it configures Gatekeeper's own operational behavior (sync, webhook settings, exempt namespaces), not policy logic. Option C is wrong because PolicyDefinition is not a Gatekeeper resource — it is a term from other policy engines (like Kyverno's ClusterPolicy or Azure Policy's policy definition), not Gatekeeper.

29
MCQeasy

Which GitOps tool provides a dedicated CLI called 'argocd'?

A.Kyverno
B.Flux
C.Helm
D.ArgoCD
AnswerD

Argo CD ships the argocd command-line interface for managing applications, syncing clusters and inspecting diff state. No other GitOps tool in the list exposes that specific binary name, so it uniquely satisfies the stem's CLI requirement.

Why this answer

ArgoCD ships with a dedicated command-line interface called `argocd`, used to log in, manage applications, sync, and inspect cluster state. The CLI is a first-class part of the ArgoCD project and is documented alongside the web UI. This is a defining characteristic of ArgoCD among GitOps tools.

Exam trap

CGOA often tests tool-to-CLI mapping, and candidates confuse ArgoCD with Flux or Helm because all three appear in GitOps pipelines — the key is that `argocd` is unique to ArgoCD.

How to eliminate wrong answers

Option A is wrong because Kyverno is a policy engine with its own CLI (`kyverno`), not `argocd` — it validates and mutates resources rather than performing GitOps sync. Option B is wrong because Flux uses the `flux` CLI (and `fluxctl` historically), not `argocd`. Option C is wrong because Helm is a package manager with the `helm` CLI for chart installation, not a GitOps controller and not `argocd`.

30
Multi-Selectmedium

When evaluating ArgoCD vs Flux, which TWO of the following are distinct advantages of using Flux?

Select 2 answers
A.Built-in web-based graphical dashboard
B.RBAC managed via UI
C.Visual sync waves
D.Modular, controller-based architecture
E.Native support for multi-repo reconciliation
AnswersD, E

Flux ships as independent controllers — source-controller, kustomize-controller, helm-controller, notification-controller — each installable and upgradable separately. ArgoCD bundles its reconciliation logic into one monolithic application, so Flux's granular components satisfy the modularity advantage the stem asks for.

Why this answer

Option D is correct because Flux is built as a set of independent Kubernetes controllers (source-controller, kustomize-controller, helm-controller, notification-controller), each with a single responsibility, which allows operators to install only the components they need and to scale or upgrade them independently — a modular design that contrasts with ArgoCD's more monolithic application-server model. Option E is correct because Flux natively reconciles multiple Git repositories through multiple GitRepository sources, each watched by its own Kustomization or HelmRelease, so a single Flux installation can continuously reconcile many repos without extra tooling. The unmarked options do not belong: A and B describe ArgoCD's strengths, since ArgoCD ships a built-in web UI with graphical RBAC management, whereas Flux is CLI/GitOps-centric and configures RBAC through Kubernetes manifests; C is also an ArgoCD feature, as ArgoCD provides visual sync waves and health status in its dashboard, while Flux expresses ordering via dependsOn and health checks rather than a graphical sync-wave view.

Exam trap

The trap is that candidates attribute ArgoCD's UI-centric features (dashboard, visual sync waves, UI RBAC) to Flux, or assume both tools are architecturally identical — the exam tests whether you know Flux's modular controllers and native multi-repo support are its distinguishing strengths.

31
Multi-Selecthard

When configuring Kyverno policies to secure a cluster, which TWO of the following actions can a policy perform?

Select 2 answers
A.Enforce policies by blocking requests
B.Provision new clusters
C.Manage Git repository webhooks
D.Automatically upgrade cluster nodes
E.Audit policies to report non-compliance
AnswersA, E

Kyverno's validating admission webhook intercepts API server requests and rejects non-compliant resources, satisfying the enforcement requirement. Unlike audit mode, which only logs violations, blocking prevents non-conforming workloads from ever being created, directly meeting the stem's demand for an action a policy can perform.

Why this answer

Kyverno is a Kubernetes-native policy engine that operates as a validating and mutating admission controller, so option A is correct: a policy in Enforce mode causes the admission webhook to reject (block) any request that violates the rule, returning a denial to the API server. Option E is also correct: Kyverno policies can run in Audit mode, where violations are not blocked but are recorded as PolicyReports (and ClusterPolicyReports) that surface non-compliant resources for review. The remaining options are outside Kyverno's scope: provisioning new clusters (B) is done by tools like Cluster API, kubeadm, or Terraform; managing Git repository webhooks (C) belongs to Git hosting platforms or CI/CD systems such as GitHub/GitLab; and automatically upgrading cluster nodes (D) is handled by node lifecycle tooling like kubeadm upgrade, Cluster API, or managed-node upgrade features, not by a policy engine.

Exam trap

CGOA often tests whether candidates know Kyverno's scope is in-cluster policy (enforce/audit/mutate/generate) and not cluster provisioning, Git webhooks, or node upgrades — those belong to other tools.

32
Multi-Selecthard

Which THREE of the following are essential tasks when implementing SOPS with GitOps?

Select 3 answers
A.Enabling Git LFS for encrypted files
B.Running a custom CI/CD build to decrypt
C.Configuring the KMS or local key (e.g., Age)
D.Storing the private key in the cluster as a secret
E.Creating a .sops.yaml config file
AnswersC, D, E

SOPS encrypts values using a key source, so configuring the KMS key or a local Age keypair is mandatory before any file can be encrypted or decrypted. Without this key material, the GitOps pipeline cannot decrypt secrets at reconciliation time.

Why this answer

Option C is correct because SOPS needs a key source to encrypt/decrypt data: either a cloud KMS (AWS KMS, GCP KMS, Azure Key Vault) or a local key such as an Age keypair, and this must be configured before any SOPS operation works. Option D is correct because in a GitOps flow the cluster-side controller (e.g., Flux's kustomize-controller or Argo CD) must be able to decrypt at apply time, so the private key (Age identity or KMS credentials) has to be mounted into the cluster as a Secret. Option E is correct because the .sops.yaml file defines the creation rules that map file paths to the KMS keys or Age recipients used for encryption, ensuring consistent, reproducible encryption across the repository.

Option A is not essential: Git LFS is a storage optimization for large binaries and is unrelated to SOPS, which encrypts values in place within YAML/JSON files. Option B is not essential: SOPS decryption is performed natively by the GitOps controller (or the sops binary), so a custom CI/CD build step to decrypt is unnecessary and would actually break the GitOps principle of the cluster reconciling encrypted manifests directly.

Exam trap

CGOA often tests the misconception that CI/CD pipelines should decrypt secrets; the GitOps principle is that the cluster-side controller decrypts using a key stored in the cluster, not a custom build step.

33
Multi-Selectmedium

Which TWO of the following are true about ArgoCD ApplicationSets?

Select 2 answers
A.They support multi-cluster generators
B.They are only for local clusters
C.They handle container image builds
D.They automate application creation
E.They replace the need for Git
AnswersA, D

ApplicationSets include a cluster generator that discovers registered clusters and produces one Application per cluster, enabling fleet-wide deployment. This satisfies the multi-cluster requirement by templating Applications across many clusters from a single ApplicationSet definition, without hand-writing each Application manifest.

Why this answer

Option A is correct because ApplicationSets provide generators such as the Cluster generator, which enumerates clusters registered in ArgoCD (via cluster Secrets) and produces one Application per cluster, enabling true multi-cluster deployments. Option D is correct because an ApplicationSet controller renders a template against generator output to automatically create, update, and delete ArgoCD Application resources, removing the need to hand-write each Application manifest. Option B is wrong since ApplicationSets are explicitly designed to target many clusters, not just the local one.

Option C is wrong because ApplicationSets only generate Application CRs; image building is handled by CI tools like Jenkins, GitLab CI, or Tekton, not ArgoCD. Option E is wrong because ApplicationSets still rely on Git (or another generator source) as the desired-state source of truth and do not replace it.

Exam trap

CGOA often tests the misconception that ApplicationSets are a CI/build tool or a Git replacement, when they are purely a declarative fan-out mechanism for generating ArgoCD Applications from Git-defined desired state.

34
MCQmedium

You are debugging an ArgoCD sync failure. You find the 'Sync Status' is 'Failed'. Where is the most detailed error information located?

A.Sync Result in Application UI
B.ApplicationSet status
C.Git log
D.ArgoCD repo server logs
AnswerA

The Sync Result panel in the Application UI exposes the granular kubectl-style diff and apply errors produced during reconciliation, including which resource failed and the API server's rejection message. It satisfies the need for the most detailed error information beyond the summary Sync Status field.

Why this answer

The Sync Result in the Application UI provides the most detailed error information for a failed sync. It shows the exact error message from the sync operation, including which resource failed, the reason (e.g., validation error, conflict, or apply failure), and often the full output from kubectl apply. This is the primary place to diagnose sync failures because it aggregates the results of the sync attempt.

Exam trap

CGOA often tests the misconception that logs (repo server or application controller) contain the most detailed sync error, when actually the Application's Sync Result in the UI is the primary source for sync failure details.

How to eliminate wrong answers

Option B is wrong because ApplicationSet status only reports the health and sync status of the generated Applications, not the detailed error from a specific sync operation. Option C is wrong because Git log only shows commit history and does not contain information about ArgoCD sync failures. Option D is wrong because ArgoCD repo server logs may contain errors related to repository access or manifest generation, but they do not provide the detailed sync result for a specific application; they are more relevant for repo connectivity issues.

35
MCQeasy

You are using Argo CD to deploy an application. You want to ensure that Argo CD automatically synchronizes the application whenever the Git repository changes. Which sync policy should you configure?

A.Manual sync policy with self-heal enabled
B.Automated sync policy without self-heal
C.Manual sync policy with auto-prune enabled
D.Automated sync policy with self-heal enabled
AnswerB

An automated sync policy without self-heal will automatically synchronize the application when the Git repository changes, but it will not revert manual changes made directly to the cluster. This precisely meets the requirement of automatic synchronization on Git changes without additional enforcement.

Why this answer

To automatically synchronize on Git changes, you need an automated sync policy. Self-heal is a separate setting that reverts manual cluster changes; it is not required for automatic sync on Git changes. Therefore, automated sync without self-heal is the correct choice.

Exam trap

The trap here is conflating automated sync with self-heal, and thinking that self-heal is necessary for automatic synchronization.

36
MCQhard

You are managing secrets using SOPS with Age. You notice that Flux cannot decrypt the files. What is the most likely cause?

A.Missing private key secret in the flux-system namespace
B.SOPS version mismatch
C.Network latency
D.Incorrect git branch
AnswerA

Flux's kustomize-controller decrypts SOPS files using the Age private key stored as a Kubernetes secret in the flux-system namespace. Without that key present, decryption fails and reconciliation errors occur, so the missing secret is the most likely cause of the failure.

Why this answer

Flux's kustomize-controller and helm-controller perform SOPS decryption in-cluster using the Age private key, which must be present as a Kubernetes Secret named 'sops-age' in the flux-system namespace (referenced via the decryption.secretRef field). If that Secret is missing or the key doesn't match the Age recipient used to encrypt the files, Flux logs 'failed to decrypt' errors and reconciliation fails. SOPS version, network latency, and git branch have no bearing on the in-cluster decryption step.

Exam trap

CGOA often tests the misconception that SOPS decryption happens client-side or via Git credentials, when in fact Flux requires the Age private key to be mounted as an in-cluster Secret in the flux-system namespace.

How to eliminate wrong answers

Option B is wrong because SOPS version mismatches rarely break decryption — Age ciphertext is stable across SOPS versions and Flux bundles its own SOPS library, so version skew is not the typical failure mode. Option C is wrong because network latency only affects Git polling and API calls, not the local cryptographic decryption performed by the controller. Option D is wrong because an incorrect git branch would prevent Flux from fetching the manifests at all (a source/reconciliation error), not produce a decryption failure on files it already pulled.

37
MCQhard

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?

A.Post-sync hooks
B.dependsOn
C.Sync waves
D.Reconciliation intervals
AnswerB

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.

Why this answer

Flux's dependsOn field in a Kustomization or HelmRelease resource declares dependencies, ensuring that one resource is reconciled only after its dependencies are ready. This replicates ArgoCD's Sync Waves behavior, where resources are applied in ordered waves. dependsOn provides the same ordering guarantee by gating reconciliation on dependency health.

Exam trap

CGOA often tests whether candidates assume Flux has a direct 'sync waves' equivalent, when the correct mapping is dependsOn—a dependency graph rather than numbered waves.

How to eliminate wrong answers

Option A is wrong because post-sync hooks in ArgoCD run after sync completes and are not a Flux feature for ordering reconciliation; Flux does not have an equivalent 'post-sync hook' primitive. Option C is wrong because 'Sync Waves' is an ArgoCD-specific concept, not a Flux feature—Flux uses dependsOn instead. Option D is wrong because reconciliation intervals control how often Flux checks for drift, not the order in which resources are applied.

38
MCQmedium

In a GitOps workflow, what is the best way to handle a configuration that must be different for production versus development clusters?

A.Copy-pasting the manifest files
B.Using environment variables
C.Kustomize overlays
D.Running multiple ArgoCD instances
AnswerC

Overlays keep one shared base and apply environment-specific patches for each cluster, avoiding duplicated manifests that drift apart. This satisfies the stem's requirement that production and development differ while remaining maintainable from a single source.

Why this answer

Kustomize overlays let you maintain a single base set of manifests and apply environment-specific patches (replica counts, resource limits, image tags, ConfigMaps) via overlays for dev, staging, and prod. This keeps configuration DRY, reviewable in Git, and avoids drift, which is exactly what GitOps requires. ArgoCD and Flux both natively support Kustomize, making overlays the canonical pattern for environment differentiation.

Exam trap

CGOA often tests the misconception that environment variables or separate ArgoCD instances handle environment differences, when the GitOps-idiomatic answer is Kustomize overlays (or Helm values).

How to eliminate wrong answers

Option A is wrong because copy-pasting manifests creates duplicated sources of truth that drift apart and violate GitOps single-source-of-truth principles. Option B is wrong because environment variables alone cannot express structural manifest differences (e.g., different replicas, ingress hosts, or resource requests) and are not a GitOps-native configuration mechanism. Option D is wrong because running multiple ArgoCD instances does not solve configuration differentiation — it adds operational overhead and still requires a mechanism (like overlays) to vary the manifests per environment.

39
Multi-Selecteasy

Which TWO of the following are common GitOps challenges?

Select 2 answers
A.Drift between Git and live state
B.Lack of Git repository
C.Too many developers
D.Securely managing secrets
E.Too much documentation
AnswersA, D

Drift between Git and live state is a core GitOps challenge: manual changes or failed reconciliations let the cluster diverge from the declared desired state in Git. Continuous reconciliation by controllers such as Argo CD or Flux detects and corrects this, satisfying the stem's requirement for a common GitOps challenge.

Why this answer

Option A is correct because a core GitOps challenge is configuration drift — the live cluster state diverging from the desired state declared in Git — which occurs when changes are made directly to the cluster (e.g., via kubectl) or when reconciliation fails, requiring continuous sync tools like Argo CD or Flux to detect and remediate it. Option D is correct because Git repositories are plaintext and version-controlled, so storing Kubernetes Secrets, credentials, and tokens directly in Git exposes sensitive data; teams must adopt solutions such as Sealed Secrets, SOPS, External Secrets Operator, or HashiCorp Vault to manage secrets securely. Option B is not a GitOps challenge because Git is the foundational prerequisite of GitOps — the entire model depends on a Git repository as the single source of truth, so its absence is a setup failure rather than a common operational challenge.

Option C is not a GitOps-specific challenge because having many developers is a general team-scaling concern, and Git's branching, pull-request, and review workflows are specifically designed to handle large contributor bases. Option E is not a challenge because documentation volume is unrelated to GitOps mechanics; if anything, GitOps improves traceability through commit history and declarative manifests.

Exam trap

CGOA often tests whether candidates pick generic team or documentation issues as GitOps challenges, when the exam expects the two canonical technical pain points: drift and secrets.

40
MCQeasy

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?

A.Elimination of external cluster credentials in CI
B.Faster build times
C.Automatic unit testing
D.No need for Git
AnswerA

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.

Why this answer

In a pull-based GitOps model, the in-cluster agent (Flux or ArgoCD) runs inside the Kubernetes cluster and pulls the desired state from Git. Because the agent already has in-cluster credentials via its ServiceAccount, the CI system never needs kubeconfig or cluster-admin credentials to deploy — it only commits to Git. This dramatically shrinks the attack surface and removes the need to store long-lived cluster credentials in CI secrets.

Exam trap

CGOA often tests the misconception that pull-based GitOps is about speed or testing; the real differentiator is credential isolation — CI never holds cluster credentials because the in-cluster agent pulls from Git.

How to eliminate wrong answers

Option B is wrong because build times are determined by the CI runner and Docker build steps, not by whether deployment is push or pull — pull-based models often add a reconciliation delay. Option C is wrong because unit testing is a CI pipeline concern (e.g., running dotnet test or go test) and is entirely orthogonal to the deployment mechanism. Option D is wrong because Git is the fundamental source of truth in GitOps; both push and pull models require a Git repository to store the declarative manifests.

Ready to test yourself?

Try a timed practice session using only Tooling questions.