Courseiva

CCNA Gitops Patterns Questions

57 questions · Gitops Patterns · All types, answers revealed

Practice these questionsDomain overviewAll questions
1
MCQeasy

What is the purpose of the 'destination' field in an Argo CD Application manifest?

A.It defines the sync frequency.
B.It defines the user who triggered the sync.
C.It defines the Git repository URL.
D.It defines the target Kubernetes cluster and namespace.
AnswerD

The destination field specifies the target cluster's API server URL (or name) and the namespace where Argo CD deploys the application's manifests. This satisfies the stem's requirement by identifying precisely where synced resources land, separating deployment location from source repository and sync policy configuration.

Why this answer

The destination field in an Argo CD Application manifest specifies the target Kubernetes cluster (by server URL or name) and the namespace where the application's resources will be deployed. It tells Argo CD where to apply the manifests from the source repository. This is essential for multi-cluster deployments.

Exam trap

CGOA often tests the confusion between source (Git repo) and destination (cluster/namespace) fields in an Argo CD Application manifest.

How to eliminate wrong answers

Option A is wrong because sync frequency is controlled by syncPolicy (e.g., automated sync with selfHeal) or manually triggered, not by the destination field. Option B is wrong because the user who triggered a sync is recorded in audit logs or annotations, not in the destination field. Option C is wrong because the Git repository URL is defined in the source field, not destination.

Practice this question →
2
Multi-Selectmedium

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?

Select 3 answers
A.Install Argo CD control plane components on every edge cluster
B.Configure the 'server.enable.proxy' flag in the hub cluster
C.Ensure the service account for Argo CD has cluster-admin permissions on target clusters
D.Define Application projects to restrict cluster access
E.Create Argo CD cluster secrets in the management cluster namespace
AnswersC, D, E

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.

Why this answer

In a hub-and-spoke Argo CD topology, the hub cluster runs the Argo CD control plane and manages remote edge clusters as external targets, so option C is correct because the Argo CD application-controller's service account (or the credential stored in the cluster secret) must have sufficient RBAC—typically cluster-admin or an equivalent scoped role—on each target cluster to create, update, and delete the deployed resources. Option D is correct because Argo CD AppProjects are the mechanism that restricts which clusters (destinations) and namespaces an Application may target, enforcing multi-tenancy and preventing a project from deploying to unauthorized edge clusters. Option E is correct because remote clusters are registered by creating cluster Secrets (labeled argocd.argoproj.io/secret-type: cluster) in the Argo CD namespace on the hub, containing the target server URL and credentials, which is how the hub knows and authenticates to each spoke.

Option A is incorrect because installing the Argo CD control plane on every edge cluster describes a distributed/standalone model, not hub-and-spoke, where only the hub runs the control plane. Option B is incorrect because there is no 'server.enable.proxy' flag required for this pattern; remote access is handled through cluster Secrets and the argocd-server/application-controller, not such a flag.

Exam trap

CGOA often tests whether candidates confuse the hub-and-spoke model with a multi-instance Argo CD deployment, so the trap is selecting 'install Argo CD on every cluster' as if it were required for centralized management.

Practice this question →
3
MCQeasy

In the context of GitOps, what is 'Configuration Drift'?

A.A security vulnerability in the container image.
B.The movement of traffic between blue and green environments.
C.The difference between the cluster state and the Git repository state.
D.The time taken for a Git commit to reach the production cluster.
AnswerC

Configuration drift describes divergence between the live cluster state and the desired state declared in Git, the single source of truth. GitOps tooling such as Argo CD or Flux continuously reconciles this difference, detecting when manual changes or failures push the cluster away from the committed manifests.

Why this answer

Configuration drift in GitOps is the divergence between the desired state declared in the Git repository and the actual state running in the cluster. GitOps controllers such as Argo CD or Flux continuously reconcile the cluster toward Git, and drift is detected when the live state no longer matches the declared manifests — for example, after a manual kubectl edit or an out-of-band change.

Exam trap

CGOA often tests the distinction between drift (state divergence from Git) and deployment latency or security scanning, so candidates who see 'difference' and 'cluster' may pick a timing or vulnerability answer instead of the state-mismatch definition.

How to eliminate wrong answers

Option A is wrong because a container image vulnerability is a security concern addressed by image scanning (e.g., Trivy, Clair), not by the GitOps concept of drift. Option B is wrong because traffic movement between blue and green environments is a deployment strategy (blue/green) and is unrelated to state divergence. Option D is wrong because the time for a commit to reach production is deployment latency or sync time, not drift; drift is about state mismatch, not timing.

Practice this question →
4
MCQmedium

You notice your GitOps operator is performing too many API calls to the Kubernetes API server. What is the most likely configuration issue?

A.The sync policy 'syncPeriod' is set too low.
B.The Git repo is too large.
C.The operator has too many permissions.
D.The cluster is running too many pods.
AnswerA

A low syncPeriod forces the operator to reconcile and poll the Kubernetes API far more frequently than needed, inflating request volume. Raising syncPeriod reduces polling frequency while webhook-driven reconciliation still applies changes promptly, cutting API server load.

Why this answer

The 'syncPeriod' (or reconciliation interval) controls how often the GitOps operator polls Git and the cluster for drift. If it is set too low (e.g., every few seconds), the operator makes excessive API calls to the Kubernetes API server, causing load and potential throttling. Increasing the interval reduces API pressure.

Exam trap

CGOA often tests the misconception that Git repo size or cluster pod count drives API call volume, when the real cause is an overly aggressive syncPeriod (reconciliation interval) set too low.

How to eliminate wrong answers

Option B is wrong because a large Git repo affects Git fetch/render time, not Kubernetes API call volume — the operator still only applies manifests, and repo size does not drive API call frequency. Option C is wrong because excessive permissions do not cause more API calls; permissions affect what the operator can do, not how often it polls. Option D is wrong because running many pods increases cluster load generally but does not directly cause the GitOps operator to make more API calls — the operator's call rate is governed by its sync configuration.

Practice this question →
5
Multi-Selecthard

Which THREE of the following are necessary to prevent 'Secret Sprawl' in a multi-cluster environment? (Select three)

Select 3 answers
A.Using External Secrets Operator to sync secrets to specific namespaces.
B.Using a dedicated Secret Management system (e.g., HashiCorp Vault).
C.Applying RBAC policies to ensure only specific apps can access secrets.
D.Granting 'cluster-admin' to the GitOps operator service account.
E.Storing encrypted secrets in the Git repository.
AnswersA, B, C

External Secrets Operator pulls from an external store and materialises Kubernetes Secrets only into the namespaces that need them, rather than replicating credentials cluster-wide. This narrows each secret's blast radius, directly limiting the sprawl the scenario describes across multiple clusters.

Why this answer

Option A is correct because the External Secrets Operator (ESO) pulls secrets from an external provider and syncs them only into the specific namespaces that need them, eliminating the practice of duplicating or scattering secret copies across every cluster and namespace. Option B is correct because a dedicated secret management system such as HashiCorp Vault (or AWS Secrets Manager, Azure Key Vault) provides a single authoritative source of truth with centralized lifecycle, rotation, and auditing, which is the core defense against secret sprawl. Option C is correct because RBAC policies scoped to specific ServiceAccounts and namespaces ensure only the intended applications can read a given secret, preventing the broad, uncontrolled access that fuels sprawl.

Option D is not correct because granting cluster-admin to the GitOps operator service account massively over-privileges it and worsens the blast radius rather than preventing secret sprawl. Option E is not correct because storing secrets in Git—even encrypted—still proliferates copies across repositories and clusters and is not a substitute for a centralized secret management system with controlled sync and access.

Exam trap

CGOA often tests the misconception that encrypting secrets in Git (SOPS/Sealed Secrets) is sufficient to prevent sprawl, when the exam expects a dedicated secret manager plus scoped sync plus RBAC.

Practice this question →
6
MCQhard

When using Argo CD, how do you handle applications that require resources to be created in a specific order (e.g., CRDs before Operators)?

A.Use multiple Git repositories.
B.Disable automated sync and run it twice.
C.Use syncWaves annotations.
D.Use a single massive YAML file.
AnswerC

Sync-wave annotations assign each resource a wave number; Argo CD applies lower-numbered waves and waits for them to become healthy before proceeding, so CRDs are established before the Operators that depend on them are created.

Why this answer

Argo CD supports sync waves via the argocd.argoproj.io/sync-wave annotation, which lets you assign an integer wave number to each resource. Argo CD applies resources in ascending wave order, waiting for each wave to become healthy before proceeding to the next. This is the canonical way to ensure CRDs are applied before the Operators or custom resources that depend on them.

Exam trap

The trap is assuming that file order or repository structure controls apply order — Argo CD ignores YAML file ordering and requires explicit sync-wave annotations to sequence resources.

How to eliminate wrong answers

Option A is wrong because splitting manifests across multiple Git repositories does not control apply order — Argo CD still syncs each Application independently and provides no cross-repo ordering guarantee. Option B is wrong because disabling automated sync and manually running sync twice is a fragile workaround that does not guarantee CRDs are established before dependent resources are applied. Option D is wrong because a single massive YAML file does not enforce ordering — kubectl/Argo CD apply order within a file is not guaranteed to match the file's textual order.

Practice this question →
7
MCQmedium

You are troubleshooting a multi-cluster Argo CD deployment where the 'staging' cluster is healthy but 'production' cluster is 'OutOfSync' despite having the same manifest source. Why might this happen?

A.The production cluster has a newer version of the Kubernetes API.
B.A manual 'kubectl apply' was performed on the production cluster.
C.The 'staging' cluster is using a different Argo CD instance.
D.The Git repo is only cloned to the staging cluster.
AnswerB

A manual `kubectl apply` on production mutates live resources outside Git, so Argo CD's diff detects drift between the desired manifest and actual cluster state, reporting `OutOfSync`. The staging cluster remains untouched and healthy, satisfying the stem's constraint that identical manifest sources yield divergent sync statuses.

Why this answer

Argo CD determines sync status by comparing the desired state in Git with the live state in the cluster. If someone runs kubectl apply directly on the production cluster, the live state diverges from Git, so Argo CD reports OutOfSync even though the manifest source is identical. The staging cluster remains healthy because its live state still matches Git.

Exam trap

CGOA often tests the core GitOps principle that the cluster's live state must match Git — the trap is blaming the Git repo or Argo CD instance instead of recognising manual drift as the cause of OutOfSync.

How to eliminate wrong answers

Option A is wrong because a newer Kubernetes API version on production would not by itself cause OutOfSync if the manifests are compatible; Argo CD compares desired vs live state, not API versions. Option C is wrong because using a different Argo CD instance for staging would not explain production being OutOfSync — each instance compares its own cluster to Git. Option D is wrong because Argo CD does not 'clone the repo to the cluster'; it fetches from Git and applies to the cluster, so repo cloning location is irrelevant.

Practice this question →
8
MCQhard

Your organization uses a 'Git-branch-per-environment' strategy. You notice that hotfixes applied to the 'production' branch are being overwritten by automatic merges from the 'staging' branch. Which GitOps promotion pattern should you adopt to prevent this drift?

A.Enable Argo CD 'automated.allowEmpty' sync options.
B.Switch to a repository structure using Kustomize overlays with a single branch.
C.Implement an automated CI job to force push the staging branch to production.
D.Use Argo CD ApplicationSets with a 'git' generator to deploy only from the main branch.
AnswerB

Kustomize overlays with a single branch separate environment-specific configuration from shared base manifests, so promotion patches are applied declaratively rather than merged across branches. This prevents staging merges from overwriting production hotfixes, eliminating the drift the branch-per-environment strategy caused.

Why this answer

A single-branch repository with Kustomize overlays (B) separates environment-specific configuration (replicas, image tags, resource limits) into overlay directories while sharing a common base, so hotfixes applied to production are not overwritten by staging merges. Argo CD then syncs each overlay to its target cluster, eliminating branch-merge drift. This is the recommended GitOps promotion pattern for avoiding cross-branch overwrites.

Exam trap

CGOA often tests whether candidates recognize branch-per-environment as the root cause of drift and know that overlay-based promotion (Kustomize/Helm) is the fix, rather than reaching for Argo CD sync flags that do not address the merge problem.

How to eliminate wrong answers

Option A is wrong because 'automated.allowEmpty' only permits syncing an application when the rendered manifests are empty — it does nothing to prevent staging merges from overwriting production hotfixes. Option C is wrong because force-pushing staging to production destroys production-only commits and is a destructive anti-pattern, not a promotion strategy. Option D is wrong because ApplicationSets with a git generator deploy from branches/directories but do not by themselves solve the overwrite problem if production and staging still share a merge path; the root issue is branch-per-environment, which must be replaced by overlay-based promotion.

Practice this question →
9
MCQmedium

During a blue-green deployment, what is the primary role of the traffic manager (e.g., Istio or Nginx Ingress)?

A.To build the container image.
B.To monitor the Git repository for changes.
C.To split traffic between versions to reduce risk.
D.To store application logs.
AnswerC

The traffic manager controls the routing layer, shifting a defined proportion of requests from the blue version to the green version. This gradual split limits the blast radius of a faulty release, satisfying the deployment's need to reduce risk during cutover.

Why this answer

In a blue-green deployment, the traffic manager (e.g., Istio, Nginx Ingress) is responsible for routing and splitting traffic between the blue (current) and green (new) versions. This allows controlled exposure of the new version, enabling canary testing or immediate rollback if issues arise, thereby reducing deployment risk. It does not build images, monitor Git, or store logs.

Exam trap

CGOA often tests the specific responsibility of the traffic manager in blue-green deployments — candidates may confuse it with CI/CD components like image builders or Git monitors.

How to eliminate wrong answers

Option A is wrong because building container images is the role of a CI system like Jenkins or GitLab CI, not the traffic manager. Option B is wrong because monitoring the Git repository is the function of a GitOps operator such as Argo CD or Flux, not the ingress controller. Option D is wrong because log storage is handled by logging stacks (e.g., ELK, Loki), not the traffic manager.

Practice this question →
10
MCQmedium

Which Argo CD feature allows you to manage multiple applications with shared configuration?

A.ApplicationSets.
B.Sync Waves.
C.Application Projects.
D.Resource Hooks.
AnswerA

ApplicationSets use generators to template and deploy many Argo CD Applications from one shared definition, so common configuration such as repository, sync policy and destination is defined once. This is the feature purpose-built for managing multiple applications with shared configuration across clusters.

Why this answer

ApplicationSets is the Argo CD controller that generates multiple Application resources from a single template combined with generators (List, Cluster, Git, Matrix, Merge, Pull Request). It is purpose-built for managing many applications that share configuration, such as one app per cluster or per tenant.

Exam trap

The trap is mixing up ApplicationSets (fan-out generation of Applications) with AppProjects (tenancy/policy) and Sync Waves (ordering), since all three appear in multi-app discussions.

How to eliminate wrong answers

Option B is wrong because Sync Waves control the ordering of resource application within a single sync (using the argocd.argoproj.io/sync-wave annotation), not the generation of multiple applications. Option C is wrong because AppProjects are tenancy and policy boundaries that restrict source repos and destinations, not a templating mechanism for shared config. Option D is wrong because Resource Hooks are lifecycle jobs (PreSync, Sync, PostSync, SyncFail) that run around a sync, not a way to fan out applications.

Practice this question →
11
MCQmedium

In 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?

A.Modify the global ConfigMap in the Argo CD namespace
B.Add the cluster URL to the Git repository manifest
C.Use the argocd cluster add command to store credentials as a secret in the Argo CD namespace
D.Manually create a Kubernetes secret in the remote cluster
AnswerC

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.

Why this answer

The 'argocd cluster add' command is the standard way to register an external cluster with Argo CD. It creates a ServiceAccount in the target cluster, generates a kubeconfig, and stores the credentials as a Secret in the Argo CD namespace, allowing Argo CD to manage the remote cluster.

Exam trap

CGOA often tests the specific command for adding clusters, and candidates might think manual Secret creation in the remote cluster is sufficient, overlooking that Argo CD needs the credentials stored locally.

How to eliminate wrong answers

Option A is wrong because modifying a ConfigMap does not handle cluster credentials; Argo CD uses Secrets for sensitive data. Option B is wrong because adding the cluster URL to a Git manifest does not provide authentication credentials. Option D is wrong because manually creating a Secret in the remote cluster does not give Argo CD the necessary access; the credentials must be stored in the Argo CD cluster.

Practice this question →
12
MCQeasy

What is the main advantage of using a 'Declarative' approach to system management?

A.It requires less storage in Git.
B.It allows you to skip CI/CD testing.
C.You can use imperative commands like 'kubectl run'.
D.It makes system state predictable and reproducible.
AnswerD

Declarative management defines the desired end state rather than imperative steps, so the tooling converges the system to that specification regardless of starting conditions. This satisfies the stem's advantage: identical declarations yield predictable, reproducible state across environments and repeated runs.

Why this answer

A declarative approach describes the desired end state of the system, and the tooling continuously reconciles the actual state to match it. This makes the system state predictable and reproducible, because the same declaration applied to any environment yields the same result, and drift can be detected and corrected automatically.

Exam trap

CGOA often tests the contrast between declarative and imperative management — the trap is picking an option that sounds like a benefit (less storage, skip testing) but is either false or unrelated to the declarative paradigm.

How to eliminate wrong answers

Option A is wrong because declarative manifests are not inherently smaller in Git — they can be larger than imperative scripts, and storage is not the advantage. Option B is wrong because declarative management does not remove the need for CI/CD testing; in fact, testing is essential to validate the declared state. Option C is wrong because imperative commands like kubectl run are the opposite of the declarative approach — they issue direct actions rather than declaring desired state.

Practice this question →
13
MCQhard

You are using a 'Pull' based GitOps model (e.g., Flux or Argo CD). Why is it considered more secure than a 'Push' based CI/CD model?

A.It allows faster deployment times.
B.It does not require a container registry.
C.It is easier to configure with SSH keys.
D.It eliminates the need for cluster credentials on the CI server.
AnswerD

In a pull model the in-cluster agent (Flux or Argo CD) initiates outbound connections to fetch desired state, so the CI server never holds kubeconfig or cluster credentials. This removes the high-value attack target that a push pipeline's stored credentials represent.

Why this answer

In a Pull-based GitOps model, the agent (Flux or Argo CD) runs inside the target cluster and pulls the desired state from Git. The CI system never needs kubeconfig credentials or cluster-admin tokens to push manifests, so a compromise of the CI pipeline cannot be used to directly mutate the cluster. This removes the most dangerous credential exposure path in traditional push-based pipelines.

Exam trap

CGOA often tests the misconception that pull-based GitOps is 'more secure' because of encryption or authentication features, when the real reason is credential isolation — the CI server never holds cluster credentials.

How to eliminate wrong answers

Option A is wrong because deployment speed is not the security differentiator — pull and push models can both be fast, and speed is irrelevant to the threat model. Option B is wrong because both pull and push models still require a container registry to host images; the registry is orthogonal to the GitOps sync mechanism. Option C is wrong because SSH key configuration is not inherently easier in pull mode — pull agents typically use HTTPS tokens or deploy keys, and SSH ease-of-use is not a security property.

Practice this question →
14
MCQmedium

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?

A.The deployment strategy is set to 'Immediate' instead of 'Canary'.
B.The Prometheus query for success rate is returning no data.
C.The Git repository is in read-only mode.
D.The service mesh sidecar is missing the 'canary' annotation.
AnswerB

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.

Why this answer

The most common reason for canary analysis failure in Flagger despite a stable new version is that the Prometheus query for success rate returns no data. Flagger relies on metrics from Prometheus to evaluate canary health; if the query is misconfigured or returns empty, Flagger interprets this as failure and rolls back. This is a frequent configuration issue.

Exam trap

CGOA often tests the dependency of Flagger on Prometheus metrics — candidates may overlook that missing metrics data causes analysis failure, not the stability of the new version.

How to eliminate wrong answers

Option A is wrong because if the deployment strategy were 'Immediate', Flagger would not perform canary analysis at all; the question states canary analysis is failing, implying it is configured. Option C is wrong because Git repository read-only mode would prevent updates but not cause canary analysis failure; Flagger would not even start. Option D is wrong because a missing 'canary' annotation on the sidecar is not a standard requirement; Flagger uses its own custom resources and annotations on the deployment, not the sidecar.

Practice this question →
15
MCQeasy

What does the 'prune' policy in GitOps do?

A.It deletes resources from the cluster that are no longer in Git.
B.It cleans up old container logs.
C.It synchronizes the Git repo with the latest upstream changes.
D.It restarts pods that have been running for too long.
AnswerA

Pruning compares live cluster resources against the Git-declared desired state and removes anything absent from Git, preventing configuration drift. This enforces Git as the single source of truth, satisfying the GitOps reconciliation requirement that cluster state matches the repository.

Why this answer

The prune policy in GitOps deletes resources from the cluster that are no longer present in Git, ensuring the cluster state matches the declared desired state exactly. Without pruning, removed manifests would leave orphaned resources running, causing drift between Git and the live cluster.

Exam trap

CGOA often tests the confusion between pruning and syncing — candidates may pick the sync option, but pruning specifically means deleting cluster resources that no longer exist in Git.

How to eliminate wrong answers

Option B is wrong because cleaning up old container logs is a logging or retention concern, not a GitOps reconciliation behavior. Option C is wrong because synchronizing the Git repo with upstream changes describes a Git pull or sync operation, not pruning, which acts on cluster resources. Option D is wrong because restarting long-running pods is a remediation or liveness-probe action, not a prune policy, which is about removing resources absent from Git.

Practice this question →
16
Multi-Selectmedium

Which TWO of the following help ensure successful multi-cluster GitOps rollouts? (Select two)

Select 2 answers
A.Deploying to all clusters at the same time.
B.Using only one Git repository for all cluster configurations.
C.Using canary deployment phases per cluster group.
D.Grouping clusters by geography or environment for staggered rollouts.
E.Hardcoding cluster IPs in the manifest files.
AnswersC, D

Canary phases promote a release through successive cluster groups, exposing each increment to real traffic before widening it. This limits blast radius per stage and provides verification checkpoints, satisfying the stem's requirement for successful multi-cluster GitOps rollouts rather than a single simultaneous push.

Why this answer

Option C is correct because canary deployment phases per cluster group let you roll out changes to a small subset of clusters first, validate health and metrics, and only then promote the change to the remaining groups, which limits blast radius and enables safe progressive delivery. Option D is correct because grouping clusters by geography or environment (for example, dev → staging → prod, or region-by-region) supports staggered rollouts so that failures are detected in lower-risk groups before reaching production or other regions. Option A is wrong because deploying to all clusters simultaneously maximizes blast radius and removes any opportunity to catch a bad change before it affects everything.

Option B is wrong because a single Git repository for all cluster configurations is not a requirement for successful multi-cluster GitOps and can create coupling and coordination problems; separate repos or directory structures are common and valid. Option E is wrong because hardcoding cluster IPs in manifests makes configurations brittle and non-portable, breaking the declarative, environment-agnostic nature of GitOps.

Exam trap

CGOA often tests the trade-offs between speed and safety in multi-cluster rollouts, and candidates may incorrectly think that deploying to all clusters at once or using a single repo is efficient, ignoring risk and isolation.

Practice this question →
17
Multi-Selecthard

Which THREE of the following represent advanced GitOps patterns for multi-cluster management? (Select three)

Select 3 answers
A.ApplicationSets with custom generators.
B.GitOps-driven traffic management with Service Mesh.
C.Policy-as-Code for multi-cluster compliance.
D.Always using a single cluster for everything.
E.Using manual shell scripts for cluster provisioning.
AnswersA, B, C

ApplicationSets with custom generators let one definition target many clusters, satisfying the multi-cluster constraint. Generators such as cluster, git, or matrix dynamically produce per-cluster Applications, so a single source of truth fans out configuration without duplicating manifests.

Why this answer

Option A is correct because Argo CD ApplicationSets use generators (such as cluster, git, list, matrix, and merge generators) to automatically template and deploy Applications across many clusters from a single definition, which is a core advanced GitOps multi-cluster pattern. Option B is correct because GitOps-driven traffic management with a service mesh (for example Istio or Linkerd) stores routing, failover, and canary rules declaratively in Git and reconciles them across clusters, enabling progressive delivery and cross-cluster traffic control. Option C is correct because Policy-as-Code for multi-cluster compliance uses tools like Open Policy Agent/Gatekeeper or Kyverno to enforce and audit policies consistently across clusters, with policy definitions versioned and reconciled via GitOps.

Option D is not an advanced multi-cluster pattern; consolidating everything into a single cluster contradicts the goal of multi-cluster management and creates a single point of failure. Option E is not GitOps at all, since manual shell scripts for cluster provisioning are imperative, non-declarative, and not continuously reconciled from a Git source of truth.

Exam trap

The trap is selecting options that are either too basic (single cluster) or anti-GitOps (manual scripts), mistaking them for advanced patterns; the exam expects you to recognize that advanced patterns involve automation, scalability, and declarative configuration.

Practice this question →
18
MCQhard

You are using Argo CD to manage a production application. A developer accidentally commits a change that sets the replica count to zero, and the change is merged to the main branch. You want to prevent this from happening again without blocking all changes to the repository. Which GitOps pattern should you implement?

A.Implement a policy-as-code admission controller that rejects manifests with a replica count of zero in production.
B.Enable Argo CD's auto-sync with self-heal and set a minimum replica count in the Application spec.
C.Use Argo CD's sync waves to order the deployment so that the replica count is applied last.
D.Configure a pre-sync hook that runs a script to check the replica count and fails the sync if it is zero.
AnswerA

A policy-as-code admission controller, such as OPA Gatekeeper or Kyverno, can validate manifests before they are applied. By defining a policy that rejects replica counts of zero in production namespaces, you prevent the bad state from being reconciled. This pattern enforces guardrails without blocking all repository changes, aligning with GitOps security practices.

Why this answer

Policy-as-code admission controllers enforce rules at admission time, preventing invalid manifests from being applied. A policy that rejects replica counts of zero in production directly addresses the scenario and acts as a guardrail. This pattern is a core GitOps practice for ensuring compliance and preventing misconfigurations without hindering normal development.

Exam trap

The trap here is thinking that Argo CD's sync features can enforce value constraints, but they only control timing and reconciliation, not validation.

Practice this question →
19
MCQhard

When configuring an App-of-Apps pattern, which field in the 'Application' manifest controls the order in which child applications are deployed?

A.argocd.argoproj.io/sync-wave
B.spec.project
C.spec.syncPolicy.automated.prune
D.spec.source.targetRevision
AnswerA

Sync-wave annotations on child Applications make Argo CD apply them in ascending wave order, so lower-numbered waves finish before higher ones begin. This directly satisfies the stem's requirement to control deployment ordering within the App-of-Apps pattern.

Why this answer

In the App-of-Apps pattern, the argocd.argoproj.io/sync-wave annotation on each child Application controls the order in which Argo CD applies them. Argo CD processes resources in ascending wave order (negative waves first, then zero, then positive), waiting for each wave to become healthy before proceeding to the next, which lets you sequence dependencies such as CRDs before the operators that use them.

Exam trap

CGOA often tests whether candidates know that ordering in App-of-Apps is controlled by the sync-wave annotation rather than by any spec field, so candidates who see 'order' and 'Application manifest' frequently pick spec.project or spec.syncPolicy instead of the annotation.

How to eliminate wrong answers

Option B is wrong because spec.project designates the AppProject that governs RBAC and permitted source/destination repositories; it has no effect on deployment ordering. Option C is wrong because spec.syncPolicy.automated.prune controls whether resources removed from Git are deleted from the cluster during automated sync, not the order of deployment. Option D is wrong because spec.source.targetRevision specifies the Git revision (branch, tag, or commit) to deploy from, which affects what is deployed, not the sequence in which applications are applied.

Practice this question →
20
MCQmedium

What happens if the 'revision' in an Argo CD Application points to a branch that does not exist?

A.It will create the branch automatically.
B.It will stop the Argo CD controller.
C.The application will be marked as 'Invalid' or 'Degraded'.
D.It will sync the 'main' branch instead.
AnswerC

Argo CD resolves the target revision against the repository when syncing. If the named branch is absent, resolution fails, so the Application cannot render desired manifests and its status becomes Invalid or Degraded rather than Synced, satisfying the scenario's non-existent branch constraint.

Why this answer

If the revision points to a non-existent branch, Argo CD cannot resolve the desired state, so the Application's sync status becomes Unknown/Invalid and health may show Degraded or Missing. It does not fall back to another branch or create one. The controller continues running; only that Application is affected.

Exam trap

CGOA often tests the misconception that Argo CD will fall back to a default branch or auto-create a missing branch, when it actually surfaces an Invalid/Degraded status without changing Git.

How to eliminate wrong answers

Option A is wrong because Argo CD never creates branches in Git; it is a read-only consumer of the repository. Option B is wrong because a bad revision affects only the Application's reconciliation, not the Argo CD controller process, which keeps managing other Applications. Option D is wrong because Argo CD does not silently substitute main; it reports an error rather than syncing an unintended branch.

Practice this question →
21
MCQmedium

You want to use Helm for your GitOps deployments. Where should the 'values.yaml' file reside for environment-specific overrides?

A.In the Git repository, per environment.
B.In a local machine folder not tracked by Git.
C.In the Argo CD global settings.
D.Inside the container image.
AnswerA

GitOps treats Git as the single source of truth, so environment-specific values.yaml overrides must be committed per environment in the repository. Argo CD then renders the chart against the correct values file for each target environment.

Why this answer

Environment-specific values.yaml overrides must live in Git, organized per environment (e.g., envs/dev/values.yaml, envs/prod/values.yaml), so the GitOps operator can render the chart with the correct values for each target cluster. This keeps Git as the single source of truth and makes environment differences reviewable and auditable.

Exam trap

The trap is thinking values can live in the operator's global config or the image — GitOps requires all desired-state inputs, including values files, to be versioned in Git.

How to eliminate wrong answers

Option B is wrong because a local, untracked folder is invisible to the GitOps operator and breaks reproducibility — no one else can see or review the values. Option C is wrong because Argo CD global settings (argocd-cm) are for platform configuration, not per-application Helm values; values belong with the app in Git. Option D is wrong because baking values into a container image couples configuration to the artifact, prevents per-environment overrides, and violates the separation of build and deploy.

Practice this question →
22
Multi-Selecteasy

Which THREE of the following are benefits of using the App-of-Apps pattern? (Select THREE)

Select 3 answers
A.Centralized management of multiple applications.
B.Elimination of the need for Helm.
C.Simplified visualization of related applications in the UI.
D.Ability to sync all related applications with one click.
E.Automatic promotion of code between environments.
AnswersA, C, D

A root Application points to a directory of child Application manifests, so many applications are declared and governed from one parent resource. This gives a single entry point for managing a fleet of related deployments.

Why this answer

Option A is correct because the App-of-Apps pattern uses a parent Argo CD Application that points to a Git repository containing multiple child Application manifests, giving a single control point to manage many applications declaratively. Option C is correct because Argo CD renders the parent and its child Applications as a hierarchical tree in the UI, making it easy to visualize the relationships and health of related applications. Option D is correct because syncing the parent Application triggers reconciliation of the child Application resources, allowing all related applications to be synced together from one action.

Option B is not correct because App-of-Apps is an Argo CD application organization pattern and does not remove the need for Helm or any other templating/packaging tool. Option E is not correct because App-of-Apps does not perform automatic promotion of code between environments; promotion is handled by separate CI/CD or GitOps promotion workflows.

Exam trap

The trap is attributing unrelated capabilities (eliminating Helm, auto-promoting environments) to App-of-Apps, when its actual benefits are centralized management, visualization, and one-click sync.

Practice this question →
23
MCQmedium

You are performing a Canary deployment using Argo Rollouts. You notice that the analysis template is failing even though the metrics are within range. What is the most common cause of this in a GitOps workflow?

A.The analysis template is missing the 'rollback' flag.
B.The Prometheus metric query does not match the 'args' passed from the Rollout object.
C.The Rollout image version is not updated in the Git repository.
D.The ReplicaSet is failing to scale to the desired state.
AnswerB

Argo Rollouts substitutes the Rollout's args into the AnalysisTemplate's Prometheus query by name. If a placeholder in the query does not exactly match the corresponding arg key, the query renders empty or malformed, so the analysis fails despite healthy metrics.

Why this answer

In Argo Rollouts canary deployments, the AnalysisTemplate defines metrics queries (e.g., Prometheus PromQL) and can accept arguments passed from the Rollout's analysis step. If the query references template variables (like {{args.service-name}}) that don't match the args defined in the Rollout's analysis step, the query fails to render or returns invalid results, causing the analysis to fail even when actual metrics are healthy. This mismatch is the most common GitOps misconfiguration.

Exam trap

CGOA often tests whether candidates can distinguish between analysis failures caused by configuration mismatches (args/query) versus actual metric threshold breaches, causing them to chase metric issues when the real problem is template parameterization.

How to eliminate wrong answers

Option A is wrong because there is no 'rollback' flag in an AnalysisTemplate — rollback behavior is controlled by the Rollout's strategy (e.g., aborting on failure), not a template flag. Option C is wrong because an outdated image version in Git would prevent the new version from deploying at all, not cause analysis failure while metrics are in range. Option D is wrong because ReplicaSet scaling failures are a symptom of resource or scheduling issues, not a cause of analysis template failures when metrics are healthy.

Practice this question →
24
MCQmedium

In a GitOps promotion pipeline, why is it recommended to tag container images with a unique Git commit SHA instead of 'latest'?

A.Because the container registry requires unique SHAs.
B.To reduce the size of the container image.
C.Because 'latest' is deprecated by Docker.
D.To ensure immutability and auditability.
AnswerD

SHA-based tagging is essential for reliable GitOps.

Why this answer

Tagging container images with a unique Git commit SHA ensures immutability because the tag directly corresponds to a specific commit, making it easy to trace back to the exact source code. This provides auditability, as you can always identify which code version is running. Using 'latest' is mutable and can lead to inconsistent deployments.

Exam trap

CGOA often tests the importance of immutability in GitOps, and candidates may incorrectly think that 'latest' is deprecated or that registries require unique tags, missing the core reason of auditability and immutability.

How to eliminate wrong answers

Option A is wrong because container registries do not require unique SHAs; they allow any tag, including 'latest', though best practices recommend unique tags. Option B is wrong because the tag does not affect the size of the container image; image size is determined by layers and content. Option C is wrong because 'latest' is not deprecated by Docker; it is still a valid tag, but it is discouraged for production due to mutability.

Practice this question →
25
MCQeasy

When deploying across multiple clusters using Argo CD, you need to ensure that specific secrets are only available to clusters located in the 'us-east' region. Which resource should you use to enforce this segregation?

A.AppProject
B.ConfigMap
C.ApplicationSet
D.ClusterRoleBinding
AnswerA

AppProject scopes permitted source repositories, destination clusters and namespaces, so a project limited to the us-east cluster destination prevents Applications elsewhere from referencing those secrets. This enforces the regional segregation the stem requires through Argo CD's native tenancy boundary.

Why this answer

AppProject is the Argo CD resource that provides logical grouping and multi-tenancy boundaries, including restricting which clusters, namespaces, and repositories a set of Applications may target. By defining a destination cluster allow-list scoped to the us-east region inside an AppProject, you enforce that only Applications bound to that project can deploy secrets to those clusters. This is the intended mechanism for segregating resources by region or environment.

Exam trap

CGOA often tests the misconception that ApplicationSet or ConfigMap can enforce multi-tenancy boundaries, when only AppProject provides the source/destination allow-list scoping.

How to eliminate wrong answers

Option B is wrong because a ConfigMap is a Kubernetes object for storing non-sensitive configuration data and cannot enforce RBAC or cluster-scoping policies in Argo CD. Option C is wrong because ApplicationSet is a generator that templatizes Application creation across clusters; it does not itself restrict which clusters a given secret may reach. Option D is wrong because ClusterRoleBinding is a native Kubernetes RBAC object that grants permissions to subjects cluster-wide and has no awareness of Argo CD projects or regional segregation.

Practice this question →
26
Multi-Selectmedium

Which TWO of the following are features of progressive delivery in GitOps? (Select two)

Select 2 answers
A.Gradual traffic shifting between application versions.
B.Manually logging into pods to check health.
C.Automated rollback based on custom metrics.
D.Immediate deployment of all changes to the entire cluster.
E.Removing all health checks from the application.
AnswersA, C

Gradual traffic shifting between application versions satisfies the incremental exposure constraint of progressive delivery. Unlike blue-green deployment, which flips all traffic at once, this mechanism routes a controlled percentage of requests to the new version, enabling canary analysis and rapid rollback before full rollout.

Why this answer

Option A is correct because progressive delivery in GitOps is fundamentally about gradually shifting traffic between application versions—using techniques like canary releases or blue-green deployments—so that a new version receives only a small percentage of traffic initially and that share increases as confidence grows. Option C is correct because progressive delivery tightly couples traffic shifting with automated analysis of custom metrics (e.g., error rate, latency, or business KPIs); if those metrics breach defined thresholds, the rollout is automatically rolled back, which is a core GitOps progressive delivery capability. Option B is not a feature of progressive delivery—manually logging into pods is an ad-hoc, non-automated troubleshooting step that contradicts the automated, declarative nature of GitOps.

Option D is incorrect because immediate deployment of all changes to the entire cluster is a big-bang release, the opposite of progressive delivery's incremental rollout. Option E is incorrect because removing health checks would eliminate the very signals progressive delivery relies on to validate a rollout and trigger automated rollback.

Exam trap

The trap is confusing progressive delivery with simple automated deployment — candidates pick 'immediate deployment' or 'manual checks' when the defining features are gradual traffic shifting plus metric-driven automated rollback.

Practice this question →
27
Multi-Selectmedium

Which TWO of the following are valid strategies for promoting an application from staging to production in GitOps? (Select two)

Select 2 answers
A.Deleting the application and recreating it.
B.Running a 'kubectl rollout undo' command manually.
C.Merging a pull request from a staging branch to a production branch.
D.Bypassing the CI/CD pipeline by pushing directly to the cluster.
E.Updating the environment-specific values file in the production directory.
AnswersC, E

Merging a staging branch into production makes Git the single source of truth: the merge commit triggers the GitOps controller to reconcile production to the newly declared state, satisfying the requirement for a Git-driven, auditable promotion strategy.

Why this answer

Option C is correct because in GitOps the Git repository is the single source of truth, so promoting an application is done by merging a pull request from a staging branch into a production branch, which changes the desired state that the GitOps operator (e.g., Argo CD or Flux) then reconciles into the production cluster. Option E is correct because GitOps commonly uses a directory-per-environment layout (e.g., kustomize overlays or Helm values files), so updating the environment-specific values file in the production directory commits the new desired production configuration, which the GitOps controller detects and applies. Option A is not a valid promotion strategy because deleting and recreating the application discards state and is not a declarative Git-driven promotion.

Option B is not valid because 'kubectl rollout undo' is an imperative manual rollback that bypasses Git and would be reverted by the GitOps reconciler. Option D is not valid because pushing directly to the cluster bypasses the CI/CD pipeline and Git, violating the core GitOps principle that all changes flow through Git.

Exam trap

CGOA often tests the principle that GitOps promotions must be declarative and Git-centric — candidates may choose manual kubectl commands or direct cluster pushes, which violate GitOps.

Practice this question →
28
MCQmedium

You are using Kustomize 'overlays' for environment promotion. If you need to add a specific label to all resources in production but not in staging, where should you define it?

A.In the 'overlays/production' kustomization.yaml file.
B.In the global GitOps config map.
C.By modifying the manifest manually after deployment.
D.In the 'base' directory kustomization.yaml file.
AnswerA

Kustomize builds each overlay by layering its kustomization.yaml over the shared base, so a label declared only in overlays/production appears solely in production output. Staging, using its own overlay, never inherits it, satisfying the environment-specific constraint.

Why this answer

In Kustomize, overlays are used to customize base resources for different environments. To add a label only in production, you define it in the production overlay's kustomization.yaml using the 'commonLabels' or 'labels' field. This ensures the label is applied only to resources in that overlay.

Exam trap

CGOA often tests the distinction between base and overlay, and candidates may incorrectly place environment-specific customizations in the base, affecting all environments.

How to eliminate wrong answers

Option B is wrong because a global GitOps config map is not part of Kustomize and does not affect resource manifests. Option C is wrong because manual modification after deployment is not declarative and would be overwritten by GitOps sync. Option D is wrong because defining the label in the base would apply it to all environments, including staging.

Practice this question →
29
MCQeasy

What is the primary benefit of using a 'Git Branch' promotion pattern over a 'Directory-based' promotion pattern?

A.It eliminates the need for CI pipelines.
B.It allows teams to use PRs to review configuration changes for specific environments.
C.It requires less storage space in the Git repository.
D.It automatically synchronizes all branches to the cluster simultaneously.
AnswerB

Git branch promotion isolates each environment's configuration on a dedicated branch, so changes reach that environment only through a pull request. This satisfies the stem's review constraint: PR approvals, diffs and status checks gate promotion, whereas directory-based promotion merges environments into one branch and cannot enforce per-environment review.

Why this answer

The Git branch promotion pattern maps each environment to its own branch, so promoting a change means opening a pull request from, say, staging to production. This enables peer review, approval workflows, and a clear audit trail of what was promoted and by whom, which is a major governance advantage over directory-based patterns.

Exam trap

CGOA often tests the misconception that branch-based promotion eliminates CI or reduces storage, when its real advantage is PR-driven review and environment isolation.

How to eliminate wrong answers

Option A is wrong because Git branch promotion still relies on CI pipelines to build, test, and validate artifacts; it does not eliminate them. Option C is wrong because branches duplicate file content across the repository, generally using more storage, not less, compared to a single directory tree. Option D is wrong because Argo CD does not automatically sync all branches to the cluster simultaneously; each Application targets a specific branch or path, and syncing all branches would cause conflicts and drift.

Practice this question →
30
MCQeasy

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?

A.Application
B.SyncPolicy
C.ArgoCD Project
D.AppProject
AnswerA

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.

Why this answer

The App-of-Apps pattern uses an Argo CD Application as the parent, whose manifests are themselves child Application resources stored in Git. The parent Application syncs a directory containing child Application YAML definitions, and Argo CD then creates and manages those child Applications, each deploying its own workload. This recursive use of the Application CRD is what gives the pattern its name.

Exam trap

The trap is confusing the parent Application with AppProject: candidates see 'project' in the options and pick it, but the App-of-Apps parent is always an Application resource referencing child Application manifests.

How to eliminate wrong answers

Option B is wrong because SyncPolicy is a field within an Application spec (defining automated sync, prune, self-heal), not a standalone resource type used as a parent. Option C is wrong because 'ArgoCD Project' is not a real resource; the correct term is AppProject, and it is a governance boundary, not the parent app. Option D is wrong because AppProject defines source/destination restrictions and RBAC scope for Applications, but it does not reference child application manifests.

Practice this question →
31
MCQeasy

You have a GitOps pipeline where you want to promote a change from Staging to Production. Using Argo CD, what is the recommended way to perform this promotion?

A.Update the ApplicationSet generator to point to a different branch.
B.Run 'argocd app sync' pointing to the staging image.
C.Update the version in the Git manifest for the Production Application and commit.
D.Use the 'kubectl patch' command on the production deployment.
AnswerC

Git is the single source of truth in GitOps, so promotion happens by editing the Production Application's manifest to the new image version and committing. Argo CD then reconciles the cluster to match that declared state, keeping the change auditable and reversible.

Why this answer

In a GitOps model, Git is the single source of truth, so promotion between environments must be performed by changing the desired state in Git, not by imperative commands. Updating the version in the Production Application's manifest and committing it lets Argo CD detect the drift and reconcile the cluster to match. This preserves auditability, rollback via Git revert, and declarative consistency.

Exam trap

CGOA often tests the misconception that promotion can be done by syncing an app to a different source or by imperative kubectl commands, when GitOps strictly requires committing the desired state to Git.

How to eliminate wrong answers

Option A is wrong because changing the ApplicationSet generator branch affects which manifests are generated for the ApplicationSet, not the promotion of a specific versioned artifact to Production, and it would disrupt the environment mapping. Option B is wrong because 'argocd app sync' merely reconciles the cluster to whatever Git already declares; it cannot point to a staging image and would either be a no-op or cause drift, violating GitOps principles. Option D is wrong because 'kubectl patch' is an imperative out-of-band change that Argo CD would detect as drift and revert, breaking the GitOps contract and audit trail.

Practice this question →
32
Multi-Selecthard

Which THREE of the following are essential security practices for GitOps? (Select three)

Select 3 answers
A.Giving every developer direct 'cluster-admin' access.
B.Strict RBAC for both the Git repository and the Kubernetes cluster.
C.Using OPA Gatekeeper to enforce security policies on manifests.
D.Encrypting secrets before storing them in Git (e.g., SOPS).
E.Sharing the Git repository password with all cluster users.
AnswersB, C, D

GitOps grants the pipeline write access to production, so repository and cluster permissions must be tightly scoped. Strict RBAC limits who can merge manifest changes and which service accounts can apply them, preventing a compromised contributor or over-privileged controller from deploying unauthorised workloads.

Why this answer

Option B is correct because GitOps relies on Git as the single source of truth, so strict RBAC must be applied both to the Git repository (to control who can merge manifest changes) and to the Kubernetes cluster (to limit what the GitOps controller and users can do), preventing unauthorized or overly privileged changes. Option C is correct because OPA Gatekeeper acts as a Kubernetes admission controller that enforces policies (via ConstraintTemplates and Constraints) on manifests before they are applied, ensuring deployed resources comply with organizational security rules. Option D is correct because secrets stored in Git must be encrypted beforehand, for example with SOPS (often combined with age or KMS), since Git history is persistent and plaintext secrets would be exposed to anyone with repository read access.

Option A is not appropriate because granting every developer direct cluster-admin access violates least privilege and bypasses the controlled GitOps workflow. Option E is not appropriate because sharing a Git repository password with all cluster users destroys accountability and violates the principle of unique, least-privilege credentials.

Exam trap

The trap is accepting convenience-oriented answers (shared passwords, broad admin) as 'practices' — the exam expects least privilege and policy enforcement, not operational shortcuts.

Practice this question →
33
MCQeasy

Which of the following is a core principle of GitOps?

A.Manual intervention is required to scale deployments.
B.Developers should have direct 'cluster-admin' access.
C.The system state is defined in a version-controlled repository.
D.The system state is defined by the latest CI pipeline execution.
AnswerC

Declarative desired state stored in Git gives a single version-controlled source of truth, which is the defining GitOps principle. Continuous reconciliation agents compare live cluster state against that repository and automatically correct drift, satisfying the stem's requirement for a core principle rather than a tooling detail.

Why this answer

A core principle of GitOps is that the desired state of the system is declaratively defined and stored in a version-controlled repository (like Git). This repository acts as the single source of truth, and automated tools continuously reconcile the actual state to match it. This enables versioning, auditing, and rollback capabilities.

Exam trap

CGOA often tests the misconception that GitOps is just CI/CD or that the CI pipeline defines the state, confusing the role of CI (building artifacts) with Git (defining desired state).

How to eliminate wrong answers

Option A is wrong because GitOps emphasizes automation and self-healing, not manual intervention for scaling; scaling should be automated based on the declared state. Option B is wrong because GitOps promotes least privilege and does not require developers to have direct cluster-admin access; changes are made via Git, and the operator applies them. Option D is wrong because the system state is not defined by the latest CI pipeline execution; CI pipelines build artifacts, but the desired state is stored in Git, not in pipeline runs.

Practice this question →
34
MCQeasy

What is the primary role of the 'Reconciler' in a GitOps operator?

A.To delete old pods to save memory.
B.To send notifications to Slack.
C.To build images.
D.To match the actual state to the desired state.
AnswerD

The reconciler continuously compares observed cluster state against the desired state declared in Git, then applies or reverts changes to eliminate drift. This closed-loop convergence is precisely the mechanism the stem asks for when defining the reconciler's primary role.

Why this answer

The Reconciler in a GitOps operator continuously compares the actual state of the cluster with the desired state defined in Git. Its primary role is to detect drift and automatically apply changes to bring the actual state into alignment with the desired state, ensuring consistency.

Exam trap

CGOA often tests the core function of the Reconciler, and candidates may confuse it with CI tasks like building images or with monitoring/alerting functions, missing the state-matching purpose.

How to eliminate wrong answers

Option A is wrong because deleting old pods to save memory is a specific action that might be part of reconciliation, but it is not the primary role; the Reconciler's main purpose is state matching. Option B is wrong because sending notifications to Slack is an auxiliary feature, not the core responsibility of the Reconciler. Option C is wrong because building images is typically done by CI pipelines, not by the GitOps operator's Reconciler; the Reconciler deals with deploying already-built artifacts.

Practice this question →
35
MCQmedium

You are managing a GitOps repository that contains both application manifests and cluster-wide configurations. You want to ensure that changes to cluster-wide configurations are applied before application workloads during a sync. Which Argo CD feature should you use?

A.Argo CD Projects to group cluster-wide configurations and applications separately.
B.Sync waves with negative wave numbers for cluster-wide resources.
C.ApplicationSets with a progressive sync strategy.
D.Resource hooks with a PreSync phase for cluster-wide configurations.
AnswerB

Sync waves allow you to order resources by assigning wave numbers. Negative waves are applied before positive ones, so cluster-wide configurations with negative wave numbers will be applied before application workloads. This ensures dependencies like namespaces, CRDs, or RBAC are in place first. It is a standard Argo CD pattern for ordering resource creation.

Why this answer

Sync waves are the correct feature for ordering resources during a sync. By assigning negative wave numbers to cluster-wide configurations, they are applied before application workloads that have higher wave numbers. This ensures that dependencies are satisfied and avoids race conditions, which is a common GitOps pattern for managing complex deployments.

Exam trap

The trap here is confusing sync waves with hooks; hooks are for tasks, while waves order regular resources.

Practice this question →
36
Multi-Selectmedium

Which THREE of the following are benefits of the 'App-of-Apps' pattern? (Select three)

Select 3 answers
A.It enables hierarchical synchronization of applications.
B.It ensures all applications use the exact same image tag.
C.It allows for grouping applications by project or business unit.
D.It simplifies the management of large numbers of applications.
E.It eliminates the need for container registries.
AnswersA, C, D

A root Application points to a directory of child Applications, so Argo CD syncs the parent, which then creates and syncs each child. This parent-child chain is what delivers hierarchical synchronisation, letting ordering and dependencies cascade across nested layers of the cluster.

Why this answer

Option A is correct because the App-of-Apps pattern in Argo CD uses a parent Application whose manifests define child Applications, so syncing the parent cascades sync/health to the children, enabling hierarchical synchronization. Option C is correct because the parent Application can aggregate child Application manifests organized by project or business unit, letting teams scope RBAC, sync waves, and ownership per grouping. Option D is correct because a single root Application manages many child Applications declaratively, drastically reducing the manual effort of creating and tracking large fleets of Applications.

Option B is not correct because App-of-Apps only orchestrates Application resources; it does not enforce a single image tag across workloads. Option E is not correct because container registries are still required to store and pull images regardless of how Applications are structured.

Exam trap

CGOA often tests the scope of App-of-Apps, so candidates incorrectly assume it enforces uniform image tags or replaces registries, when it is actually about hierarchical orchestration and grouping.

Practice this question →
37
MCQmedium

You are implementing a GitOps promotion workflow where each environment (dev, staging, prod) has its own Kubernetes namespace in a single cluster. Your team wants to keep the base manifests identical and only vary replicas, resource limits, and image tags per environment. Which pattern should you use to achieve this with minimal duplication?

A.Helm umbrella charts with a values.yaml per environment and a single chart that templates all resources.
B.A single set of manifests with environment-specific values injected at deploy time via CI environment variables.
C.Kustomize overlays with a base directory and per-environment overlay directories that patch the base resources.
D.Separate Git repositories for each environment, each containing fully duplicated manifests.
AnswerC

Kustomize overlays let you define a shared base and apply environment-specific patches for replicas, resource limits, and image tags. This directly matches the requirement of minimal duplication while varying only a few fields per environment. The GitOps operator reconciles the rendered output, so each namespace gets the correct configuration from a single source of truth.

Why this answer

Kustomize overlays are designed to patch a common base with environment-specific changes, such as replicas, resource limits, and image tags. This keeps the base identical and avoids duplication, while the GitOps operator renders the overlay for each environment. The result is a clean, maintainable promotion pattern that aligns with GitOps principles.

Exam trap

The trap here is assuming that any templating tool is equivalent, but Kustomize overlays are specifically suited for patching a base without duplicating manifests.

Practice this question →
38
MCQmedium

What is the primary function of an 'ApplicationSet' in Argo CD?

A.To perform unit testing on manifests.
B.To automate the creation of Argo CD Applications.
C.To manage cluster security policies.
D.To automatically update the Git repo with new commits.
AnswerB

ApplicationSet controllers use generators (Git directories, clusters, lists) plus a template to produce Application resources automatically, rather than requiring each to be hand-written. This directly fulfils the stem's requirement to automate creation of Argo CD Applications.

Why this answer

An ApplicationSet in Argo CD is a controller that automates the generation of Argo CD Applications from a template plus a generator (such as a Git directory, cluster list, or pull request generator). It allows one ApplicationSet manifest to produce many Applications, which is essential for multi-cluster and multi-tenant GitOps at scale.

Exam trap

CGOA often tests whether candidates confuse ApplicationSet with CI or policy tools, so distractors about unit testing, security policies, or Git commits tempt those who do not understand that ApplicationSet is purely an Application generator.

How to eliminate wrong answers

Option A is wrong because unit testing of manifests is not an Argo CD feature — that is handled by tools like kubeconform, conftest, or helm unittest. Option C is wrong because cluster security policies are enforced by Kubernetes RBAC, OPA/Gatekeeper, or Kyverno, not by ApplicationSet. Option D is wrong because ApplicationSet does not commit to Git; it reads from Git and creates Applications, and writing back to Git would be a CI function, not a GitOps controller function.

Practice this question →
39
MCQhard

You are using Argo Rollouts for progressive delivery. You want to execute a 'AnalysisRun' before switching traffic. Where is the 'AnalysisTemplate' defined?

A.In the Argo CD global configuration file.
B.As a Kubernetes resource in Git.
C.Hardcoded in the application binary.
D.By the Service Mesh control plane directly.
AnswerB

An AnalysisTemplate is a cluster-scoped custom resource stored in Git alongside the Rollout, which references it by name. Keeping it in Git means the analysis definition is versioned and reconciled by Argo CD, satisfying the requirement to run an AnalysisRun before traffic shifts.

Why this answer

An AnalysisTemplate is a Kubernetes custom resource (CRD) that defines how to query a metric provider (Prometheus, Datadog, etc.) and what thresholds constitute success or failure. Like all GitOps artifacts, it must be declared as a Kubernetes resource stored in Git so the operator can create AnalysisRuns from it during a rollout.

Exam trap

CGOA often tests whether candidates know AnalysisTemplates are Kubernetes CRDs stored in Git — not Argo CD global config, not mesh config, and not application code.

How to eliminate wrong answers

Option A is wrong because Argo CD's global config (argocd-cm) manages platform settings, not rollout analysis logic — AnalysisTemplates are namespaced CRDs, not global config. Option C is wrong because analysis criteria are runtime operational concerns, not application code; hardcoding them in the binary removes the ability to change thresholds without rebuilding. Option D is wrong because the service mesh control plane handles traffic routing (e.g., Istio VirtualService weights) but does not define or own AnalysisTemplates — Argo Rollouts does.

Practice this question →
40
MCQhard

In a multi-cluster GitOps environment, you are using the ApplicationSet controller with a 'Cluster Generator'. You need to add a new cluster dynamically without modifying the ApplicationSet manifest. How should you achieve this?

A.Update the ApplicationSet manifest via a manual Git commit.
B.Add a secret with the label 'argocd.argoproj.io/secret-type: cluster' to the management cluster.
C.Execute 'argocd cluster add' via the CLI.
D.Modify the 'clusters.yaml' file in the root Git repository.
AnswerB

The Cluster Generator reads cluster credentials from secrets labelled argocd.argoproj.io/secret-type: cluster in the Argo CD management cluster. Creating such a secret registers the new cluster declaratively, so the ApplicationSet discovers it automatically without any manifest edit.

Why this answer

The Argo CD ApplicationSet Cluster Generator reads cluster definitions from Secrets in the Argo CD namespace that carry the label 'argocd.argoproj.io/secret-type: cluster'. Adding such a Secret dynamically registers the new cluster, and the generator automatically produces Applications for it without editing the ApplicationSet manifest.

Exam trap

CGOA often tests the misconception that you must edit the ApplicationSet manifest or run 'argocd cluster add' to add a cluster, when the Cluster Generator actually watches labeled Secrets in the management cluster.

How to eliminate wrong answers

Option A is wrong because manually editing the ApplicationSet manifest defeats the purpose of dynamic cluster onboarding — the Cluster Generator is designed to avoid manifest changes when clusters are added. Option C is wrong because 'argocd cluster add' is a CLI convenience that ultimately creates the same Secret; it is not the mechanism the generator watches, and it requires CLI access rather than declarative GitOps. Option D is wrong because there is no 'clusters.yaml' file that Argo CD reads by default — cluster registration is via Secrets (or via the CLI which creates Secrets), not a root-repo YAML file.

Practice this question →
41
Multi-Selectmedium

When implementing multi-cluster GitOps, which THREE components are critical for success? (Select three)

Select 3 answers
A.Secure communication channel (e.g., mTLS/VPN) between management and targets.
B.A centralized management cluster (Hub).
C.A shared database for all clusters to store secrets.
D.Environment-specific configuration separation (e.g., Kustomize overlays).
E.Uniform network latency across all clusters.
AnswersA, B, D

A secure channel such as mTLS or a VPN is essential because the management cluster pushes configuration to target clusters across untrusted networks. Without mutual authentication and encryption, an attacker could intercept or spoof GitOps sync traffic, violating the stem's multi-cluster requirement for trustworthy cross-cluster communication.

Why this answer

Option A is correct because multi-cluster GitOps requires a secure communication channel such as mTLS or a VPN between the management plane and target clusters, ensuring that configuration pushes, reconciliation traffic, and credentials are protected against interception or tampering. Option B is correct because a centralized management cluster (Hub) provides the single control point that hosts the GitOps operator (e.g., Argo CD or Flux) and from which all target clusters are registered, reconciled, and observed. Option D is correct because environment-specific configuration separation via Kustomize overlays (or equivalent Helm values) lets one base manifest be safely promoted across dev/staging/prod clusters without duplicating or hard-coding per-environment differences.

Option C is not appropriate because secrets should be managed through dedicated secret stores or sealed-secrets mechanisms integrated with GitOps, not a shared database that becomes a single point of compromise and is not a standard GitOps component. Option E is not required because GitOps reconciliation is asynchronous and eventually consistent; uniform latency across clusters is neither achievable nor necessary for success.

Exam trap

CGOA often tests the misconception that a shared secrets database or uniform latency is required for multi-cluster GitOps, when the real pillars are hub, secure channel, and environment separation.

Practice this question →
42
Multi-Selectmedium

Which THREE of the following are effective ways to handle 'Configuration Drift' in a GitOps environment? (Select three)

Select 3 answers
A.Use Admission Controllers to block manual modifications.
B.Monitor 'OutOfSync' status via dashboards or alerts.
C.Deleting the cluster and recreating it daily.
D.Manual syncing every hour to fix issues.
E.Enable self-healing/automated sync in the GitOps operator.
AnswersA, B, E

Admission controllers reject manual kubectl changes that bypass Git, preventing drift at creation time rather than merely detecting it. This satisfies the stem's requirement by enforcing Git as the sole source of truth for cluster state.

Why this answer

Option A is correct because Admission Controllers (e.g., Kubernetes ValidatingAdmissionWebhooks or OPA Gatekeeper) can reject or mutate any manual kubectl apply/patch that diverges from the desired state declared in Git, preventing drift at the API-server level before it is persisted. Option B is correct because GitOps operators such as Argo CD or Flux expose an OutOfSync status (Argo CD's Application.status.sync.status or Flux's Ready/Reconciling conditions) that can be surfaced via dashboards (Grafana) or alerts (Prometheus Alertmanager), giving operators early detection of drift. Option E is correct because enabling automated sync with self-healing (Argo CD's syncPolicy.automated.selfHeal: true or Flux's reconciliation interval) makes the operator continuously reconcile the live cluster back to the Git-declared state, automatically reverting drift.

Option C is not appropriate because deleting and recreating the cluster daily is a disruptive, heavyweight operation that does not address the root cause of drift and is not a GitOps reconciliation mechanism. Option D is not appropriate because manual hourly syncing is a reactive, error-prone human process that contradicts GitOps principles of continuous automated reconciliation and does not prevent drift between syncs.

Exam trap

The trap is choosing manual or disruptive methods (like daily cluster recreation or hourly manual syncs) as valid drift-handling techniques, when the exam expects automated, preventive, and detective controls.

Practice this question →
43
MCQmedium

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?

A.Using Kustomize overlays for each environment
B.Hardcoding environment names inside the main deployment file
C.Dynamic shell scripting in the CI pipeline
D.multiple_choice
E.Copy-pasting YAML files across folders
AnswerA

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.

Why this answer

Kustomize overlays are the most robust way to apply environment-specific configurations because they let you define a common base and then layer per-environment patches for staging and production without duplicating the entire manifest. This keeps the GitOps source of truth declarative, reviewable, and free of environment-specific drift, which is exactly what the GitOps directory pattern requires.

Exam trap

CGOA often tests the misconception that environment-specific configuration should be handled by scripting or copy-pasting, when the GitOps-correct answer is a declarative overlay mechanism like Kustomize that preserves a single base and avoids drift.

How to eliminate wrong answers

Option B is wrong because hardcoding environment names inside the main deployment file couples the manifest to a single environment and breaks reuse across staging and production. Option C is wrong because dynamic shell scripting in the CI pipeline introduces imperative, non-declarative logic that is hard to audit and diverges from the GitOps principle that Git is the single source of truth. Option D is wrong because 'multiple_choice' is not a configuration technique at all.

Option E is wrong because copy-pasting YAML files across folders creates duplicated manifests that drift over time and make it easy to miss a change in one environment.

Practice this question →
44
Multi-Selecteasy

Which TWO of the following are essential when using Helm in a GitOps workflow? (Select two)

Select 2 answers
A.Ignoring the chart dependencies.
B.Defining environment-specific overrides in values files.
C.Installing Helm manually on every node in the cluster.
D.Always using the 'latest' version of the chart.
E.Storing the Helm chart and values in a Git repository.
AnswersB, E

Environment-specific overrides in values files let one chart deploy across dev, staging and production without duplication, satisfying the GitOps requirement that all desired state lives declaratively in Git. Helm merges these overrides over the chart's defaults at render time, so each environment's differences stay versioned, reviewable and reproducible.

Why this answer

Option B is correct because a GitOps workflow requires declarative, environment-specific configuration to be version-controlled; defining environment-specific overrides in values files (e.g., values-dev.yaml, values-prod.yaml) lets the same chart be deployed consistently across environments while keeping differences explicit and reviewable in Git. Option E is correct because GitOps fundamentally relies on Git as the single source of truth, so the Helm chart and its values must be stored in a Git repository to enable declarative, auditable, and automated reconciliation by tools like Argo CD or Flux. Option A is wrong because ignoring chart dependencies would break deployments that rely on subcharts or dependency resolution via Chart.yaml and requirements, which Helm needs to render manifests correctly.

Option C is wrong because Helm is a client-side CLI (or handled by the GitOps controller), not something that must be installed on every cluster node. Option D is wrong because always using the 'latest' chart version undermines reproducibility and pinning, which are essential for reliable GitOps deployments.

Exam trap

CGOA often tests the misconception that Helm must be installed on every cluster node or that 'latest' chart versions are acceptable, when GitOps demands pinned versions and Git-stored charts/values.

Practice this question →
45
Multi-Selectmedium

Which TWO of the following are common benefits of using a 'GitOps Operator'? (Select two)

Select 2 answers
A.They manually restart the server every time a change is detected.
B.They require the user to have cluster-admin privileges to see the logs.
C.They provide a single, declarative source of truth.
D.They automate the drift detection and correction loop.
E.They eliminate the need for container images.
AnswersC, D

A GitOps operator continuously reconciles cluster state against a Git repository, so the repository becomes the single declarative source of truth. This satisfies the stem's benefit requirement: desired state is versioned, auditable and authoritative, eliminating configuration drift caused by manual kubectl changes or out-of-band edits.

Why this answer

Option C is correct because a GitOps Operator treats a Git repository as the single, declarative source of truth, so the desired state of the cluster is defined in version-controlled manifests and continuously reconciled from there. Option D is correct because the operator runs a continuous reconciliation loop that compares the live cluster state against the declared state, detects drift, and automatically corrects it back to the desired configuration. Options A, B, and E are not benefits of a GitOps Operator: it does not manually restart servers on every change (it reconciles declaratively), it does not require cluster-admin privileges merely to view logs, and it does not eliminate the need for container images since workloads still run as containers.

Exam trap

CGOA often tests the misconception that GitOps operators are about server restarts or privileged log access, when their defining benefits are declarative source of truth and automated drift correction.

Practice this question →
46
MCQmedium

Which mechanism is used in a GitOps workflow to ensure that a 'Canary' deployment successfully rolls back if error rates spike?

A.Kubernetes Liveness Probes.
B.Argo Rollouts 'pause' condition.
C.Git revert commands via CI/CD.
D.Flagger AnalysisTemplates.
AnswerD

Flagger's AnalysisTemplates define the metrics queries and thresholds that the canary controller continuously evaluates during a rollout. When error rates breach the specified limits, the template triggers an automatic rollback to the last stable revision, satisfying the stem's requirement for metric-driven, unattended rollback.

Why this answer

Flagger AnalysisTemplates define the metrics, thresholds, and intervals used to evaluate a canary's health; if error rates exceed thresholds, Flagger automatically aborts and rolls back the canary. This is the mechanism purpose-built for automated canary analysis and rollback in a GitOps workflow. It integrates with service meshes and ingress controllers to shift traffic progressively.

Exam trap

CGOA often tests the confusion between liveness probes (container health) and canary analysis (traffic-based metric evaluation), causing candidates to pick probes or manual pauses instead of AnalysisTemplates.

How to eliminate wrong answers

Option A is wrong because Kubernetes Liveness Probes only restart unhealthy containers; they do not analyze error rates or roll back a canary deployment. Option B is wrong because Argo Rollouts 'pause' condition halts progression for manual or timed approval, but by itself does not automatically roll back on error-rate spikes without an AnalysisTemplate. Option C is wrong because Git revert via CI/CD is a manual or pipeline-driven action, not an automated runtime rollback triggered by live error metrics.

Practice this question →
47
MCQmedium

What is the impact of enabling 'selfHeal' in an Argo CD Application sync policy?

A.It automatically creates backups of the cluster state.
B.It automatically patches the application with the latest security updates.
C.It disables the UI for that application.
D.It automatically reverts manual changes to the cluster.
AnswerD

Self-heal makes the controller compare live cluster state with the desired manifest in Git and automatically revert any out-of-band modification, restoring the declared configuration. It does not create resources or prune them; those are separate sync policy behaviours.

Why this answer

Enabling 'selfHeal' in Argo CD's sync policy causes the application controller to automatically revert manual changes made to the cluster that deviate from the desired state in Git. This ensures that the cluster state remains consistent with the Git repository, enforcing the GitOps principle of Git as the single source of truth.

Exam trap

CGOA often tests the specific behavior of Argo CD sync policies, and candidates may confuse selfHeal with other features like automated pruning or backup, or think it applies security updates.

How to eliminate wrong answers

Option A is wrong because selfHeal does not create backups; it only reverts changes to match Git. Option B is wrong because selfHeal does not patch applications with security updates; it only syncs to the Git-defined state, which may or may not include updates. Option C is wrong because selfHeal does not disable the UI; it is a sync policy setting unrelated to UI functionality.

Practice this question →
48
MCQmedium

Why would you choose to use 'Kustomize' over 'Helm' in a GitOps workflow?

A.Because it avoids complex templating logic.
B.Because Kustomize is the only tool Argo CD supports.
C.Because it supports more advanced logic than Helm.
D.Because Kustomize requires a server-side component.
AnswerA

Kustomize uses declarative overlays and patches applied to plain YAML, so environment-specific variation is expressed without Go-template conditionals or chart packaging. This directly satisfies the stem's constraint of avoiding complex templating logic, keeping manifests readable and reviewable in Git.

Why this answer

Kustomize uses a declarative overlay model with patches and bases rather than a templating language, which avoids the complex logic, conditionals, and whitespace pitfalls of Helm templates. This makes manifests easier to read, review, and validate in a GitOps workflow where the rendered output should be predictable.

Exam trap

CGOA often tests the philosophical difference between templating (Helm) and overlaying (Kustomize), so candidates who assume 'more features equals better' pick Helm-related answers or wrongly claim Kustomize supports more logic.

How to eliminate wrong answers

Option B is wrong because Argo CD natively supports both Helm and Kustomize, as well as plain YAML and Jsonnet — Kustomize is not the only supported tool. Option C is wrong because Helm actually supports more advanced templating logic (conditionals, loops, functions) than Kustomize, which deliberately avoids logic. Option D is wrong because Kustomize is a client-side tool with no server-side component; it runs in kubectl or Argo CD's repo server.

Practice this question →
49
MCQhard

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?

A.The analysis template lacks the 'weight' parameter
B.The Flagger controller is in 'paused' mode
C.The VirtualService or HTTPRoute is not pointing to the primary service
D.The canary resource is missing a 'host' definition
AnswerC

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.

Why this answer

In Flagger blue-green deployments, the primary service receives production traffic only when the VirtualService or HTTPRoute routes to it, and Flagger manages this routing during promotion. If analysis succeeds but the primary still gets no traffic, the most likely cause is that the routing resource (VirtualService for Istio, HTTPRoute for Gateway API) is misconfigured or not pointing at the primary service. Flagger relies on that routing object to shift traffic from canary back to primary after a successful analysis.

Exam trap

CGOA often tests the assumption that successful analysis automatically guarantees traffic cutover, but candidates must remember that Flagger depends on the routing resource actually pointing to the primary service.

How to eliminate wrong answers

Option A is wrong because the weight parameter belongs to canary (weighted) analysis templates, not blue-green, which uses a different promotion mechanism based on service selectors. Option B is wrong because a paused Flagger controller would halt the entire analysis and promotion, so the analysis would not have 'successfully completed.' Option D is wrong because the host definition is required for the canary resource to be valid at all; a missing host would prevent the rollout from starting, not cause post-analysis traffic failure.

Practice this question →
50
Multi-Selectmedium

Which TWO of the following are common reasons for a deployment to be marked as 'Degraded' by Argo CD? (Select two)

Select 2 answers
A.The user manually changed a label.
B.The health checks defined for the application are failing.
C.The Argo CD controller is overloaded.
D.The Git repository is temporarily offline.
E.The application pods are in a 'CrashLoopBackOff' state.
AnswersB, E

Failing health checks directly trigger Degraded status, because Argo CD evaluates each resource's health assessment and aggregates the worst result. When a defined check reports an unhealthy state, the application's overall health becomes Degraded rather than Progressing or Healthy, satisfying the stem's condition for that status.

Why this answer

Option B is correct because Argo CD's health assessment for an Application relies on the resource health checks (built-in Lua checks or custom health checks) defined for the resource kinds; when those checks fail, the Application's health status is reported as Degraded. Option E is correct because a pod stuck in CrashLoopBackOff is evaluated by Argo CD's built-in health check for Pods/Deployments as unhealthy, which propagates to the Application as Degraded. Option A is not a health condition Argo CD evaluates — a manual label change typically shows up as OutOfSync (a sync status), not Degraded.

Option C is wrong because controller overload affects reconciliation performance and may delay status updates, but it is not itself a health state reported as Degraded. Option D is wrong because Git repository unavailability causes sync/refresh errors (e.g., ComparisonError or Unknown sync status), not a Degraded health assessment.

Exam trap

CGOA often tests the distinction between sync status and health status, causing candidates to confuse causes of OutOfSync (like manual changes or Git issues) with causes of Degraded (like failing health checks or crash-looping pods).

Practice this question →
51
MCQhard

You are using Flux CD to manage a multi-tenant cluster. Each tenant has its own Git repository and namespace. You want to ensure that a tenant's Kustomization can only deploy resources into its own namespace and cannot modify cluster-scoped resources. Which Flux feature should you configure?

A.Set the targetNamespace field in the Kustomization to the tenant's namespace and enable prune.
B.Enable the Kustomization's health checks to validate that all resources are namespaced.
C.Configure the Kustomization to use a SOPS decryption key that is scoped to the tenant's namespace.
D.Use Flux's multi-tenancy lockdown with a service account that has limited RBAC permissions.
AnswerD

Flux supports multi-tenancy by allowing you to specify a service account for impersonation. By assigning a service account with RBAC that only permits operations within the tenant's namespace, you prevent the tenant from creating or modifying cluster-scoped resources. This is the recommended pattern for isolating tenants in a shared cluster.

Why this answer

Flux's multi-tenancy lockdown uses impersonation with a restricted service account. By binding the tenant's Kustomization to a service account that only has permissions within its namespace, you enforce that it cannot create or modify cluster-scoped resources. This pattern is essential for secure multi-tenant GitOps and aligns with the principle of least privilege.

Exam trap

The trap here is thinking that targetNamespace or health checks can prevent cluster-scoped resources, but only RBAC impersonation enforces that boundary.

Practice this question →
52
MCQmedium

When setting up a multi-cluster GitOps pattern, what is the benefit of using 'Cluster Labels' in ApplicationSets?

A.It increases the speed of the Git clone.
B.It allows dynamic targeting of clusters based on attributes.
C.It reduces the number of namespaces required.
D.It encrypts the communication between clusters.
AnswerB

Cluster labels attach metadata to registered clusters, letting ApplicationSets select targets dynamically through label selectors rather than hard-coded cluster names. This satisfies the multi-cluster requirement by generating applications across whichever clusters match the specified attributes.

Why this answer

Cluster Labels in ApplicationSets allow you to select target clusters based on label selectors. This enables dynamic generation of Applications for clusters that match specific attributes, such as environment, region, or team, without hardcoding cluster names.

Exam trap

CGOA often tests ApplicationSet features, and candidates may not realize that cluster labels are used for dynamic targeting, not for performance or security.

How to eliminate wrong answers

Option A is wrong because cluster labels do not affect Git clone speed. Option C is wrong because cluster labels do not reduce the number of namespaces; they are about cluster selection. Option D is wrong because cluster labels do not encrypt communication; encryption is handled by TLS and other mechanisms.

Practice this question →
53
MCQmedium

When managing multiple environments (dev/stage/prod) in one repository, which folder structure is generally considered best practice?

A.Storing configurations in the application code folder.
B.Putting everything in a single root folder.
C.Using different Git repos for every single manifest.
D.Using environment-specific folders.
AnswerD

Environment-specific folders keep dev, stage and prod manifests isolated within one repository, letting Argo CD Applications point at distinct paths while sharing common base resources. This prevents accidental cross-environment promotion and keeps overrides explicit per environment.

Why this answer

Environment-specific folders (e.g., /dev, /stage, /prod) keep manifests for each environment isolated while sharing a single repository, enabling consistent promotion workflows and clear ownership. This structure lets GitOps tools like Argo CD or Flux target a specific path per environment without duplicating the entire repo. It also makes diffs between environments obvious and supports per-environment overlays (Kustomize) or values files (Helm).

Exam trap

CGOA often tests the misconception that isolating environments requires separate repositories, when the best practice is one repo with environment-specific folders to preserve a single source of truth.

How to eliminate wrong answers

Option A is wrong because storing configurations inside the application code folder couples deployment config to app source, breaking separation of concerns and forcing app rebuilds for config changes. Option B is wrong because a single root folder mixes dev/stage/prod manifests, causing accidental cross-environment applies and making it impossible to scope a GitOps tool to one environment. Option C is wrong because creating a separate Git repo per manifest fragments the source of truth, multiplies credential/access management, and defeats GitOps' single-repo auditability.

Practice this question →
54
MCQhard

If you have a multi-cluster setup and you want to ensure that 'production' clusters only pull images from a hardened internal registry, how can you enforce this in GitOps?

A.By changing the Argo CD global settings.
B.By hardcoding the registry URL in every pod manifest.
C.By updating the Git repository access permissions.
D.Using Admission Controllers to enforce policy.
AnswerD

Admission controllers intercept every workload request at the Kubernetes API server, rejecting pods whose image references fall outside the hardened internal registry. This enforces the production-only registry constraint cluster-wide, regardless of what the GitOps manifests declare.

Why this answer

Admission controllers in Kubernetes can intercept requests to the API server before persistence and enforce policies, such as requiring images to come from a specific registry. In a GitOps workflow, you can deploy admission controllers like OPA Gatekeeper or Kyverno via Argo CD to enforce that only images from the hardened internal registry are allowed in production clusters. This provides a policy-as-code guardrail that cannot be bypassed by developers.

Exam trap

CGOA often tests the difference between configuration management and enforcement, tricking candidates into choosing manifest hardcoding or Argo CD settings instead of admission controllers, which provide actual policy enforcement.

How to eliminate wrong answers

Option A is wrong because Argo CD global settings do not control image registries for workloads; they affect Argo CD's own behavior. Option B is wrong because hardcoding the registry URL in every manifest is not enforcement; it can be overridden and does not prevent other registries from being used. Option C is wrong because Git repository access permissions control who can push changes, not what images are deployed to clusters.

Practice this question →
55
MCQeasy

In GitOps, what is the 'Source of Truth'?

A.The running Kubernetes cluster.
B.The CI pipeline logs.
C.The container registry.
D.The Git repository.
AnswerD

In GitOps the Git repository holds the declarative desired state, and controllers continuously reconcile live clusters to match it. Every change is committed there first, making Git the single authoritative source rather than the cluster or a pipeline.

Why this answer

In GitOps, the Git repository is the single source of truth because it holds the declarative manifests that define the desired state of the entire system. All changes originate as commits, and the GitOps agent continuously reconciles the live cluster to match what is declared in Git. This makes Git the authoritative record, not the running cluster.

Exam trap

CGOA often tests the misconception that the running cluster is the source of truth, when in GitOps the cluster is the reconciled target and Git is authoritative.

How to eliminate wrong answers

Option A is wrong because the running Kubernetes cluster represents the actual state, which may drift from the desired state — it is the target of reconciliation, not the source of truth. Option B is wrong because CI pipeline logs are historical records of build activity, not declarative definitions of desired infrastructure. Option C is wrong because the container registry stores built images, which are artifacts referenced by manifests, not the authoritative configuration source.

Practice this question →
56
Multi-Selecteasy

Which TWO of the following are true about the 'Pull' model in GitOps? (Select two)

Select 2 answers
A.It improves security by removing the need for cluster credentials in CI.
B.It allows the cluster to self-reconcile state changes.
C.It is only supported for Helm charts.
D.It requires opening an inbound port on the cluster firewall.
E.It requires the CI pipeline to be active 24/7.
AnswersA, B

Because the in-cluster agent pulls manifests itself, CI only commits to Git and never authenticates to the cluster. No kubeconfig or service-account token sits in the CI system, shrinking the blast radius if that pipeline is compromised.

Why this answer

Option A is correct because in the Pull model the GitOps agent (e.g., Argo CD or Flux) runs inside the cluster and pulls desired state from Git, so the CI system never needs kubeconfig or cluster credentials to push changes, reducing the attack surface. Option B is correct because the in-cluster agent continuously watches Git and the live cluster, automatically reconciling drift so the cluster converges back to the declared state without external triggering. Option C is wrong because the Pull model is tool-agnostic and works with plain YAML, Kustomize, Helm, Jsonnet, and other manifest sources.

Option D is wrong because the agent initiates outbound connections to Git (HTTPS/SSH), so no inbound firewall port needs to be opened on the cluster. Option E is wrong because reconciliation is performed by the always-running in-cluster agent, not by a CI pipeline that must stay active 24/7.

Exam trap

CGOA often tests the misconception that Pull requires inbound firewall access or that CI must run continuously — candidates confuse the always-on reconciliation loop (in-cluster) with the CI pipeline (event-driven).

Practice this question →
57
MCQhard

You are designing a multi-cluster deployment with Argo CD. You want to avoid defining 50 individual Application manifests. Which feature should you use?

A.Argo CD ApplicationSets.
B.Helm subcharts.
C.Git submodules.
D.Kubernetes Custom Resource Definitions (CRDs).
AnswerA

ApplicationSets generate many Applications from a single template using generators such as cluster lists or Git directories, eliminating 50 hand-written manifests. Plain Application objects and Projects cannot template across clusters, so they would not reduce the duplication.

Why this answer

Argo CD ApplicationSets use generators (cluster, Git, list, matrix) to template and produce many Applications from a single manifest, so you avoid writing 50 individual Application resources. A cluster generator can automatically create one Application per registered cluster, which is exactly the multi-cluster scaling need. This is the idiomatic Argo CD feature for fleet-wide deployments.

Exam trap

CGOA often tests the misconception that Helm or Git submodules solve multi-cluster Application sprawl, when the purpose-built answer is Argo CD ApplicationSets with generators.

How to eliminate wrong answers

Option B is wrong because Helm subcharts are a packaging mechanism for composing charts, not a way to generate Argo CD Application resources across clusters. Option C is wrong because Git submodules manage nested Git repositories, not Application generation or cluster targeting. Option D is wrong because CRDs define custom resource types; while ApplicationSet itself is a CRD, using CRDs generically does not solve the 50-manifest problem.

Practice this question →

Ready to test yourself?

Try a timed practice session using only Gitops Patterns questions.

Start 20-question session