CGOA Practice Test 2 — 25 Questions

Question 1

An administrator notices that an engineer manually modified a Service loadBalancerIP in the Kubernetes live cluster using 'kubectl edit'. The cluster is managed by an automated GitOps engine configured in a pull-based model. What will happen during the next reconciliation cycle?

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

Accepted Answer

The GitOps engine will detect the drift and overwrite the live cluster state to match the declared state in Git.. In a pull-based GitOps model, the engine (e.g., Argo CD or Flux) continuously compares the live cluster state to the desired state declared in Git. When it detects drift—such as a manually edited loadBalancerIP—it overwrites the live resource to match Git, provided auto-sync/self-heal is enabled. Git is never updated from the cluster; the flow is one-directional from Git to cluster.

Answer

The GitOps engine will automatically commit the updated loadBalancerIP back to the Git repository to keep Git in sync.

Answer

The live cluster modification will block future Git commits from being fetched by the GitOps agent.

Answer

The GitOps engine will halt reconciliation permanently until an administrator manually clears the cluster error log.

Question 2

What does 'Declarative Configuration' imply in GitOps?

Accepted Answer

The system is defined by files that describe the desired final state. Declarative configuration means you write files (YAML manifests, Helm charts, Kustomize overlays) that describe the desired end state of the system, and a controller continuously reconciles actual state to match. You declare 'what' the system should look like, not 'how' to get there step by step. This is the foundation of GitOps because the declarative files can be version-controlled and diffed.

Answer

Only developers can access the system

Answer

The database is the source of truth

Answer

You must manually type every command

Question 3

Which THREE strategies are effective for managing configuration at scale in a GitOps environment?

Accepted Answer

Organizing manifests into a hierarchical directory structure.. Option B is correct because organizing manifests into a hierarchical directory structure (e.g., base/ and overlays/ per environment) lets GitOps tools like Argo CD or Flux scope and reconcile each environment independently, avoiding duplication and enabling clear ownership. Option C is correct because Kustomize uses a base plus overlay model with kustomization.yaml files to apply environment-specific patches (replicas, image tags, resource limits) without copying whole manifests, which is a standard GitOps pattern. Option D is correct because Helm charts parameterize deployments through values.yaml and templating, so one chart can render many environment-specific releases, reducing drift and duplication at scale. Option A is not appropriate because copying the entire configuration per environment creates massive duplication and drift, making updates error-prone. Option E is not appropriate because a single root-level file does not scale, creates merge conflicts, and prevents per-environment separation of concerns.

Answer

Copying the entire deployment configuration for every single environment.

Answer

Storing all configurations in a single root-level file.

Question 4

What is the best way to handle temporary, non-production overrides in a GitOps environment?

Accepted Answer

Using Kustomize overlays to apply overrides on top of the base configuration.. Kustomize overlays are the canonical GitOps pattern for environment-specific overrides: a shared base holds common manifests, and overlays patch only the fields that differ per environment (replicas, image tags, resource limits). This keeps the base DRY and the overrides declarative and version-controlled. Overlays are applied by the CD controller during reconciliation, so no manual drift is introduced.

Answer

Hardcoding all variants into the base file using if/else statements.

Answer

Leaving the cluster in a drifted state.

Answer

Editing the base manifest and pushing it.

Question 5

Which TWO of the following are common GitOps terminology used to describe the state of an application?

Accepted Answer

Desired State. In GitOps, the Desired State (B) is the declarative configuration stored in Git that defines how the application and its infrastructure should look, serving as the single source of truth that the GitOps operator continuously reconciles toward. The Live State (C), also called the observed or actual state, is the real-time condition of the running application and cluster as reported by the GitOps agent (e.g., Argo CD or Flux), which is compared against the desired state to detect drift. These two terms form the core reconciliation loop of GitOps: the controller drives the live state to match the desired state. The other options are not GitOps terminology: Temporary State (A), Future State (D), and Legacy State (E) are not standard terms used to describe application state in GitOps workflows.

Answer

Temporary State

Answer

Future State

Answer

Legacy State

Question 6

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 7

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 8

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 9

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 10

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 11

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 12

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 13

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 14

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 15

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.

Question 16

When using Argo CD, what does the 'Sync Status' 'OutOfSync' indicate?

Accepted Answer

The live state differs from the desired state in Git.. In Argo CD, 'OutOfSync' means the live Kubernetes cluster state does not match the desired state declared in the Git repository. Argo CD continuously compares the manifests in Git against the resources running in the cluster, and any difference (missing resource, changed field, extra resource) sets the Sync Status to OutOfSync. This is distinct from Health Status, which reflects whether resources are functioning correctly.

Answer

The cluster is disconnected from the network.

Answer

A new version of the application is available in the registry.

Answer

The Git repository has been deleted.

Question 17

Why is 'pull-based' reconciliation considered more secure than 'push-based' CI/CD?

Accepted Answer

Because the cluster initiates the connection.. In a pull-based model, an in-cluster agent (Argo CD, Flux) initiates outbound connections to Git and the registry, so no external system needs inbound access or cluster-admin credentials. This inverts the trust boundary: the cluster reaches out rather than an external CI server reaching in. That architectural inversion is what makes pull-based reconciliation more secure.

Answer

Because it eliminates the need for Git.

Answer

Because Git requires passwords for every pull.

Answer

Because it removes the need for container images.

Question 18

When using an 'Image Updater' with a GitOps operator, what is the automated workflow?

Accepted Answer

It detects new images and updates the manifest in Git. An Image Updater (such as Argo CD Image Updater) monitors a container registry for new image tags and, when it detects a newer version matching the configured policy, writes the updated image tag back into the Git manifest. This keeps Git as the source of truth while automating image version bumps. The GitOps operator then syncs the updated manifest to the cluster.

Answer

It manually restarts the cluster

Answer

It creates a backup of the cluster

Answer

It bypasses the git repository entirely

Question 19

In a GitOps environment, what is the role of a 'CI Pipeline'?

Accepted Answer

To validate changes and commit them to the GitOps repo. In GitOps, the CI pipeline's job is to build, test, and validate changes, then commit the resulting manifests (or updated image tags) into the GitOps repository. The GitOps operator (e.g., Argo CD or Flux) then detects the commit and reconciles the cluster to match. CI produces the desired state; the GitOps controller applies it.

Answer

To replace the GitOps operator

Answer

To execute the reconciliation loop

Answer

To handle user authentication for the cluster

Question 20

Which tool provides the most native integration for managing Kubernetes manifests using Kustomize within a GitOps workflow?

Accepted Answer

Argo CD. Argo CD is purpose-built for GitOps and natively supports Kustomize as a first-class manifest source. Its repository server recognizes kustomization.yaml files and can render Kustomize overlays directly without external tooling. Terraform, Ansible, and Jenkins are general-purpose automation tools that require custom glue code to invoke Kustomize and do not provide continuous reconciliation of Kustomize-rendered manifests.

Answer

Terraform

Answer

Ansible

Answer

Jenkins