CGOA Practice Test 4 — 10 Questions

Question 1

What is the purpose of 'App-of-Apps' pattern in Argo CD?

Accepted Answer

To manage a collection of applications via a single root application. The App-of-Apps pattern in Argo CD uses a single root Application whose manifests define multiple child Applications. Syncing the root application creates or updates all the child applications, enabling centralised management of a large collection of applications. This hierarchical approach simplifies bootstrapping and governance across many services or clusters.

Answer

To perform parallel builds

Answer

To increase the memory capacity of the cluster

Answer

To allow multiple users to edit the same file

Question 2

In GitOps, what is a 'Merge Request' (or Pull Request) used for?

Accepted Answer

To review, approve, and audit proposed changes to the desired state.. In GitOps, a Merge Request (or Pull Request) is the mechanism to propose changes to the desired state stored in Git. It enables peer review, automated validation (e.g., CI checks), and an audit trail of who approved what and when. This aligns with GitOps principles of declarative, versioned, and auditable infrastructure.

Answer

To bypass security checks.

Answer

To perform unit tests on the code.

Answer

To delete the cluster.

Question 3

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 4

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 5

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 6

Your team is using Flux CD to manage Kubernetes resources. You notice that the application status is 'Suspended'. What is the most likely reason for this state in the context of GitOps principles?

Accepted Answer

A user explicitly set the suspend field to true in the resource manifest. In Flux CD, the 'Suspended' status indicates that the reconciliation of a resource has been manually paused by setting the 'suspend' field to true in the resource manifest (e.g., spec.suspend: true). This is a deliberate action to temporarily halt automated syncs, often for maintenance or debugging. It is not caused by environmental issues like memory or connectivity.

Answer

The cluster is out of memory

Answer

The controller is unable to connect to the container registry

Answer

The Git repository contains syntax errors

Question 7

What does the 'prune' policy in GitOps do?

Accepted Answer

It deletes resources from the cluster that are no longer in Git.. 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.

Answer

It cleans up old container logs.

Answer

It synchronizes the Git repo with the latest upstream changes.

Answer

It restarts pods that have been running for too long.

Question 8

When implementing DevSecOps within a GitOps workflow, where should the automated policy enforcement (like OPA/Gatekeeper) occur?

Accepted Answer

At the Kubernetes API server using an Admission Controller like OPA Gatekeeper.. OPA/Gatekeeper runs as a Kubernetes admission controller (ValidatingAdmissionWebhook) that intercepts API server requests before objects are persisted. This enforces policy at the cluster boundary regardless of whether the change came from GitOps, kubectl, or a rogue controller — making it the authoritative enforcement point in a DevSecOps GitOps workflow.

Answer

During the Git commit process using local pre-commit hooks.

Answer

In the CI pipeline during the image scanning phase.

Answer

By manually reviewing the Git diffs before merging the pull request.

Question 9

Which of these is NOT a principle of GitOps?

Accepted Answer

Imperative manual updates.. GitOps principles are declarative desired state, versioned and immutable state in Git, automated reconciliation, and continuous drift correction. Imperative manual updates contradict the declarative model because they bypass Git as the source of truth and are not reproducible or auditable. Therefore, imperative manual updates is NOT a GitOps principle.

Answer

Versioned and immutable state.

Answer

Declarative desired state.

Answer

Automated reconciliation.

Question 10

You are using Argo CD. A developer manually scales a Deployment replica count using 'kubectl scale'. What happens next in a standard GitOps implementation?

Accepted Answer

The controller detects the drift and overwrites the manual change to match Git.. Argo CD continuously monitors the live cluster state against the desired state defined in Git. When a manual change like `kubectl scale` alters the replica count, Argo CD detects this as a drift from the Git-declared configuration. By default, Argo CD's reconciliation loop will automatically sync the application, overwriting the manual change to restore the replica count specified in Git. This enforces the GitOps principle that Git is the single source of truth.

Answer

Argo CD sends an alert but does not revert the change.

Answer

The controller updates Git to reflect the new replica count.

Answer

The change persists until the next Git commit.