CGOA Gitops Patterns Practice Test 2 — 15 Questions

Question 1

You are designing a GitOps workflow for a team that wants to use a pull-based model with Argo CD. The team requires that all changes to production be reviewed and approved before deployment, and that the deployment automatically rolls back if the application becomes unhealthy. Which two patterns should you implement? (Choose two.)

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

Configure Argo CD to sync only when a pull request is merged, using a CI pipeline to update the Git repository.. To enforce review and approval, you must gate the sync on a pull request merge, which is achieved by having a CI pipeline update Git and Argo CD sync only after merge. For automatic rollback on health failure, Argo Rollouts with analysis templates provides the necessary progressive delivery and rollback capability. Together, these patterns satisfy both requirements in a pull-based GitOps model.

Answer

Set up Argo CD notifications to alert the team when a sync fails, and manually revert the Git commit.

Answer

Use Argo CD's automated sync policy with self-heal enabled to automatically revert manual changes and reconcile to the desired state.

Answer

Enable Argo CD's automated sync with the 'prune' option and a retry strategy to handle transient failures.

Question 2

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?

Accepted Answer

Use the argocd cluster add command to store credentials as a secret in the Argo CD namespace. 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.

Answer

Modify the global ConfigMap in the Argo CD namespace

Answer

Add the cluster URL to the Git repository manifest

Answer

Manually create a Kubernetes secret in the remote cluster

Question 3

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?

Accepted Answer

The VirtualService or HTTPRoute is not pointing to the primary service. 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.

Answer

The analysis template lacks the 'weight' parameter

Answer

The Flagger controller is in 'paused' mode

Answer

The canary resource is missing a 'host' definition

Question 4

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?

Accepted Answer

Ensure the service account for Argo CD has cluster-admin permissions on target clusters. 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.

Answer

Install Argo CD control plane components on every edge cluster

Answer

Configure the 'server.enable.proxy' flag in the hub cluster

Question 5

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?

Accepted Answer

Using Kustomize overlays for each environment. 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.

Answer

Hardcoding environment names inside the main deployment file

Answer

Dynamic shell scripting in the CI pipeline

Answer

multiple_choice

Answer

Copy-pasting YAML files across folders

Question 6

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?

Accepted Answer

Application. 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.

Answer

SyncPolicy

Answer

ArgoCD Project

Answer

AppProject

Question 7

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?

Accepted Answer

The Prometheus query for success rate is returning no data.. 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.

Answer

The deployment strategy is set to 'Immediate' instead of 'Canary'.

Answer

The Git repository is in read-only mode.

Answer

The service mesh sidecar is missing the 'canary' annotation.

Question 8

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

Accepted Answer

It allows teams to use PRs to review configuration changes for specific environments.. 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.

Answer

It eliminates the need for CI pipelines.

Answer

It requires less storage space in the Git repository.

Answer

It automatically synchronizes all branches to the cluster simultaneously.

Question 9

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

Accepted Answer

argocd.argoproj.io/sync-wave. 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.

Answer

spec.project

Answer

spec.syncPolicy.automated.prune

Answer

spec.source.targetRevision

Question 10

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?

Accepted Answer

A manual 'kubectl apply' was performed on the production cluster.. 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.

Answer

The production cluster has a newer version of the Kubernetes API.

Answer

The 'staging' cluster is using a different Argo CD instance.

Answer

The Git repo is only cloned to the staging cluster.

Question 11

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

Accepted Answer

Flagger AnalysisTemplates.. 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.

Answer

Kubernetes Liveness Probes.

Answer

Argo Rollouts 'pause' condition.

Answer

Git revert commands via CI/CD.

Question 12

Which of the following is a core principle of GitOps?

Accepted Answer

The system state is defined in a version-controlled repository.. 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.

Answer

Manual intervention is required to scale deployments.

Answer

Developers should have direct 'cluster-admin' access.

Answer

The system state is defined by the latest CI pipeline execution.

Question 13

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

Accepted Answer

It defines the target Kubernetes cluster and namespace.. 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.

Answer

It defines the sync frequency.

Answer

It defines the user who triggered the sync.

Answer

It defines the Git repository URL.

Question 14

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?

Accepted Answer

In the 'overlays/production' kustomization.yaml file.. 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.

Answer

In the global GitOps config map.

Answer

By modifying the manifest manually after deployment.

Answer

In the 'base' directory kustomization.yaml file.

Question 15

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

Accepted Answer

It automatically reverts manual changes to the cluster.. 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.

Answer

It automatically creates backups of the cluster state.

Answer

It automatically patches the application with the latest security updates.

Answer

It disables the UI for that application.