CGOA Gitops Patterns — Timed 30 Questions

Question 1

You are implementing progressive delivery using Flagger. After a Canary resource is defined, which metric is most critical for Flagger to automatically rollback a deployment during a blue/green shift?

Accepted Answer

Request success rate and latency metrics. Flagger performs automated canary analysis by querying metrics from Prometheus (or another provider) and comparing the canary against the primary. The most critical metrics for deciding whether to promote or roll back are request success rate and request duration (latency) — these directly reflect user-facing health. If success rate drops below the threshold or latency exceeds the limit during the analysis interval, Flagger automatically rolls back.

Answer

Pod CPU usage

Answer

Number of running replicas

Answer

Git commit hash parity

Question 2

You are managing environment promotion by overlaying Kustomize patches for 'prod', 'staging', and 'dev'. Which TWO of the following practices follow the GitOps principle of 'single source of truth' for environment configuration?

Accepted Answer

Using a 'base' directory for common resources and 'overlays' for environment differences. Separation of base and overlays ensures that the base configuration is shared, while environment-specific differences are isolated.

Answer

Hardcoding environment-specific image tags in the base templates

Answer

Storing all environment manifests in a single monolithic flat directory

Answer

Duplicating all YAML files for every environment

Question 3

Your organization uses the App-of-Apps pattern in Argo CD to manage hundreds of microservices. You need to ensure that when a developer updates a repository structure, the root application automatically discovers and syncs new child applications without manual intervention. Which feature should be enabled in the Application resource?

Accepted Answer

Enable automated sync policy with self-healing and allow-empty. To ensure that the root application automatically discovers and syncs new child applications without manual intervention when a developer updates the repository structure, you should enable automated sync policy with self-healing and allow-empty in the Application resource. This allows Argo CD to automatically sync the root app, which will detect new child applications (via directory recursion) and create them, and self-healing ensures any manual changes are reverted.

Answer

Use the 'ignoreDifferences' field for the child application manifests

Answer

Set the sync policy to 'manual' and use a post-sync hook

Answer

Configure a manual webhook trigger on the root application

Question 4

You want to promote a microservice from staging to production using the 'Git Branch' strategy. Which configuration allows you to ensure the exact same container image SHA is used across both environments?

Accepted Answer

Use a common Helm chart with environment-specific values files.. Using a common Helm chart with environment-specific values files allows the same chart template to be rendered with different configuration for staging and production while pinning the exact same container image SHA in both. The image digest is specified in the values file (or chart defaults) and remains identical, ensuring immutable, reproducible deployments across environments. This is the GitOps-aligned way to promote artifacts without rebuilding.

Answer

Manually update the container image using kubectl edit.

Answer

Use a different container registry for production.

Answer

Change the image tag to 'production' in the deployment manifest.

Question 5

In a multi-cluster GitOps setup using Argo CD, you need to ensure that specific secrets are only synced to a production cluster. Which approach is the most secure?

Accepted Answer

Use Argo CD 'Project' resource to limit which namespaces secrets can be synced to.. The most secure approach is to use an Argo CD AppProject to restrict which namespaces and clusters a given Application can sync to, so production-only secrets are scoped to the production cluster and cannot be deployed elsewhere. AppProjects define sourceRepos, destinations (cluster and namespace), and RBAC, enforcing least privilege at the Argo CD layer. This prevents a misconfigured or compromised Application from pushing production secrets to a non-production cluster.

Answer

Store secrets in Git as plain text and use a private repository.

Answer

Use Helm post-render hooks to inject secrets at runtime.

Answer

Enable 'AllowClusterResources' in the global configuration.

Question 6

You are using the App-of-Apps pattern in Argo CD to manage hundreds of microservices. You notice that the parent application is stuck in a 'Syncing' state indefinitely. What is the most likely cause?

Accepted Answer

The child application's manifests include the parent application as a dependency.. In the App-of-Apps pattern, a parent Argo CD Application manages child Applications. If a child application's manifests include the parent application as a dependency (e.g., via a Kubernetes resource that references the parent), it creates a circular dependency. Argo CD will continuously attempt to sync the parent, which waits for the child, which in turn depends on the parent, resulting in an indefinite 'Syncing' state. This is a classic deadlock scenario.

Answer

The parent application is not using a Helm chart source.

Answer

The Argo CD API server has exceeded its connection limit.

Answer

The parent application is missing the sync-policy configuration.

Question 7

In a multi-cluster environment, you are managing resources across 50 clusters. Which pattern prevents the 'Control Plane' bottleneck?

Accepted Answer

ApplicationSets with Cluster Generators.. ApplicationSets with Cluster Generators prevent the control plane bottleneck by automatically generating Argo CD Applications for each cluster based on a cluster generator, so you do not have to create and manage 50 individual Application objects manually. This distributes the management workload and lets the ApplicationSet controller reconcile across clusters in a scalable, declarative way.

Answer

Storing all YAML in a single massive monorepo.

Answer

Manual kubectl context switching.

Answer

Centralized Cluster Management.

Question 8

Which THREE of the following are common challenges when scaling GitOps to hundreds of clusters? (Select three)

Accepted Answer

Automatic rollbacks when the Git repo is empty.. Option B is correct because an empty or malformed Git repository breaks the desired-state source of truth, and GitOps controllers such as Argo CD or Flux will either fail to reconcile or trigger unintended rollback/sync behavior when the expected manifests are missing. Option C is correct because a single central GitOps controller (for example one Argo CD instance or Flux controller) managing hundreds of clusters suffers API-server load, watch/queue contention, and reconciliation latency, so performance degradation is a well-known scaling challenge. Option E is correct because distributing secrets across many clusters and environments requires careful handling with tools like Sealed Secrets, External Secrets Operator, or SOPS, and inconsistent secret management is a major operational complexity at scale. Option A is not a GitOps scaling challenge because Dockerfiles are a build-time concern, not a GitOps reconciliation concern, and no dedicated team is inherently required. Option D is not specific to scaling GitOps to hundreds of clusters, since internet dependency affects any distributed system and is not the core scaling bottleneck.

Answer

The need for a dedicated team just to write Dockerfiles.

Answer

Increased dependency on internet speed.

Question 9

Which THREE of the following are true about 'Resource Hooks' in Argo CD? (Select three)

Accepted Answer

They can be triggered pre-sync, post-sync, or on-sync-fail.. Option A is correct because Argo CD resource hooks support the argocd.argoproj.io/hook annotation values PreSync, Sync, PostSync, SyncFail, and Skip, so hooks can indeed run before sync, after sync, or when a sync fails. Option B is correct because hooks are declared via Kubernetes annotations on the resource manifest, specifically argocd.argoproj.io/hook and optionally argocd.argoproj.io/hook-delete-policy, rather than through a separate Argo CD-specific CRD. Option E is correct because hooks exist precisely to inject custom logic (such as database migrations, smoke tests, or notifications) at defined points in the deployment lifecycle. Option C is wrong because hooks are a deployment-time mechanism inside Argo CD and do not replace the build/test/artifact stages of a CI/CD pipeline. Option D is wrong because hooks are not limited to standard pods; they can be any Kubernetes resource kind, such as Jobs, and Argo CD only treats them as hooks based on annotations.

Answer

They replace the need for the CI/CD pipeline.

Answer

They run as standard pods in the cluster.

Question 10

Which THREE of the following are standard ways to organize a Git repository for a multi-tenant environment? (Select three)

Accepted Answer

Using labels to filter resources for different tenants.. Option B is correct because labels are the standard Kubernetes/GitOps mechanism for logically partitioning resources by tenant, allowing selectors, RBAC, and policies to filter objects per tenant within a shared repository. Option C is correct because a separate Git repository per business unit or tenant provides strong isolation of code, access control, and change history, which is a common multi-tenant organizational pattern. Option D is correct because a folder-per-environment structure within one repository (for example, overlays or directories such as dev/staging/prod) is a standard way to organize manifests so each tenant or environment can be promoted independently while sharing a common base. Option A is not appropriate because storing secrets in plain text in the root folder violates security best practices and exposes credentials to anyone with repository access. Option E is not appropriate because hardcoding cluster IPs in a single global config reduces portability, breaks environment isolation, and prevents per-tenant configuration.

Answer

Storing all secrets in plain text in the root folder.

Answer

Hardcoding all cluster IPs in a single global config.

Question 11

You are implementing the App-of-Apps pattern using Argo CD. You have a root Application that points to a Helm chart containing multiple sub-Application manifests. When you update the source Git repository, some sub-applications remain in an 'OutOfSync' state while others update successfully. What is the most likely cause?

Accepted Answer

The child applications have 'automated.prune' set to false within their respective SyncPolicy objects.. The App-of-Apps pattern relies on the Argo CD controller to process the root application first. If the sub-applications are not being pruned or updated, it is often due to the 'self-heal' or 'prune' policy being disabled in the Application resource definition for the child applications.

Answer

The root application lacks the 'self-heal' parameter in its SyncPolicy.

Answer

The root application is using a recursive sync interval that is too high.

Answer

Argo CD requires a Project-level permission override for nested applications.

Question 12

When using the 'Git-generator' in ApplicationSet, you want to include only a subset of directories based on a specific file content. Which feature of ApplicationSet allows you to filter the directories discovered?

Accepted Answer

The 'selector' field within the generator.. The 'template.path' field combined with 'files' or 'directories' generators allows for granular control over which paths are included, and you can use the 'paths' field to specify glob patterns.

Answer

The 'syncPolicy' field.

Answer

The 'ignoreDifferences' field.

Answer

The 'AppProject' filter.

Question 13

Which THREE of the following are valid components or patterns used in Progressive Delivery with GitOps? (Select THREE)

Accepted Answer

AnalysisTemplates. Option B (AnalysisTemplates) is correct because Argo Rollouts uses AnalysisTemplate custom resources to define automated metric queries (e.g., Prometheus, Datadog) that gate a rollout's promotion or rollback, which is a core progressive-delivery pattern. Option C (Argo Rollouts) is correct because it is the canonical Kubernetes controller providing canary, blue-green, and experimentation rollout strategies driven declaratively from Git. Option E (Blue-Green Deployment) is correct because blue-green is one of the standard progressive-delivery strategies Argo Rollouts implements via the activeService and previewService fields, shifting traffic only after validation. Option A (Git-Branch-Per-Environment) is not a progressive-delivery component or pattern; it is a Git branching strategy and is generally discouraged in GitOps, which favors a single source of truth with directory- or overlay-based environment separation (e.g., Kustomize overlays). Option D (Argo Workflows) is a general-purpose container-native workflow engine for CI/batch jobs, not a progressive-delivery mechanism, so it does not belong here.

Answer

Git-Branch-Per-Environment

Answer

Argo Workflows

Question 14

Which TWO of the following configurations are necessary to ensure that GitOps-managed clusters in a multi-cluster setup remain isolated from one another? (Select TWO)

Accepted Answer

Implementing unique namespaces for each application.. Option B is correct because assigning each application to its own unique namespace provides logical isolation of resources within and across clusters, preventing workloads from colliding or accessing each other's objects in a shared namespace. Option C is correct because restricting cluster destinations in the AppProject object (via spec.destinations) limits which clusters an application can be deployed to, which is the core Argo CD mechanism for enforcing multi-cluster isolation and preventing cross-cluster deployment leakage. Option A is incorrect because disabling the GitOps controller on the management cluster would stop reconciliation there but does nothing to isolate the managed clusters from one another. Option D is incorrect because sharing a single Git repository across all clusters does not by itself provide isolation and can actually increase the risk of cross-cluster configuration drift or unintended deployments. Option E is incorrect because enabling automated.prune only controls garbage collection of resources removed from Git; it has no bearing on cluster isolation.

Answer

Disabling the GitOps controller on the management cluster.

Answer

Using the same Git repository for all clusters.

Answer

Enabling 'automated.prune' on all applications.

Question 15

You are adopting GitOps for a team that will deploy the same Helm chart to many ephemeral preview environments. Each environment needs a unique hostname and a different replica count, and you want to avoid maintaining a separate values file for every environment. Which GitOps pattern should you implement?

Accepted Answer

Use a Helm chart with a templated values file that derives the hostname and replica count from environment-specific parameters supplied by the GitOps operator.. The requirement is to deploy one shared Helm chart to many ephemeral environments without maintaining a values file per environment. Parameterizing the chart through values that the GitOps operator supplies at reconciliation time keeps a single source of truth in Git while allowing each environment to receive a unique hostname and replica count. The other approaches either duplicate charts, commit static rendered manifests, or require per-environment patch files, all of which increase maintenance as environments are created and destroyed.

Answer

Use Kustomize remote bases to pull a shared chart from a Git repository and apply a patch that contains the hostname and replica count for each environment.

Answer

Store the rendered Kubernetes manifests for each preview environment directly in Git and apply them with kubectl from a CI pipeline.

Answer

Create a separate Helm chart for each preview environment, with the hostname and replica count hard-coded in the chart templates.

Question 16

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

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 17

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 18

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 19

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 20

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