CGOA Practice Exam 2 — 20 Questions

Question 1

What is the primary role of the GitOps operator during the reconciliation phase?

Accepted Answer

Continuously checking if the cluster matches the desired state in Git.. The GitOps operator's core responsibility during reconciliation is to continuously compare the actual state of the cluster with the desired state declared in Git. If any drift is detected, the operator automatically applies changes to bring the cluster back into alignment. This closed-loop process ensures that Git remains the single source of truth for declarative infrastructure and applications.

Answer

Reporting the number of users connected to the cluster.

Answer

Deleting the Git repository to save space.

Answer

Compiling the application source code.

Question 2

Which THREE of the following are common GitOps tools used in the CNCF ecosystem?

Accepted Answer

Crossplane.. Crossplane (A) is a CNCF project that extends Kubernetes with custom resources to provision and manage cloud infrastructure declaratively, making it a common GitOps tool for infrastructure-as-code workflows. Flux (B) is a CNCF graduated project that continuously reconciles Kubernetes cluster state with Git repositories, embodying the core GitOps pull-based model. Argo CD (D) is also a CNCF graduated project that performs declarative, Git-based continuous delivery for Kubernetes by syncing cluster resources to a desired state stored in Git. Apache HTTP Server (C) is a general-purpose web server and MySQL (E) is a relational database; neither is a GitOps reconciliation or continuous delivery tool, so they do not belong in this list.

Answer

Apache HTTP Server.

Answer

MySQL.

Question 3

Which TWO of the following are true about ArgoCD ApplicationSets?

Accepted Answer

They support multi-cluster generators. Option A is correct because ApplicationSets provide generators such as the Cluster generator, which enumerates clusters registered in ArgoCD (via cluster Secrets) and produces one Application per cluster, enabling true multi-cluster deployments. Option D is correct because an ApplicationSet controller renders a template against generator output to automatically create, update, and delete ArgoCD Application resources, removing the need to hand-write each Application manifest. Option B is wrong since ApplicationSets are explicitly designed to target many clusters, not just the local one. Option C is wrong because ApplicationSets only generate Application CRs; image building is handled by CI tools like Jenkins, GitLab CI, or Tekton, not ArgoCD. Option E is wrong because ApplicationSets still rely on Git (or another generator source) as the desired-state source of truth and do not replace it.

Answer

They are only for local clusters

Answer

They handle container image builds

Answer

They replace the need for Git

Question 4

What is the role of a 'Webhook' in a GitOps setup?

Accepted Answer

To inform the operator of a change in the Git repository. A webhook in a GitOps setup is a notification mechanism: the Git provider (GitHub, GitLab, Bitbucket) sends an HTTP POST to the operator's endpoint whenever a push, merge, or tag occurs, prompting the operator to reconcile immediately. This reduces the latency between a Git commit and cluster convergence compared to relying solely on periodic polling.

Answer

To store encrypted credentials

Answer

To scan container images for vulnerabilities

Answer

To automatically approve pull requests

Question 5

Which of the following is considered an 'Anti-pattern' in a GitOps workflow?

Accepted Answer

Applying 'hotfixes' directly to the cluster via kubectl. Applying 'hotfixes' directly to the cluster via kubectl is an anti-pattern in GitOps because it bypasses the declarative, version-controlled workflow. GitOps requires all changes to be made through Git, ensuring auditability, reproducibility, and consistency. Direct kubectl changes cause drift and are not tracked in Git.

Answer

Storing infrastructure definitions as code

Answer

Automated testing of configuration before merging to main

Answer

Using pull requests to review configuration changes

Question 6

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?

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 7

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 8

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 9

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 10

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 11

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 12

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 13

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 14

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 15

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 16

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 17

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 18

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 19

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 20

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.