CGOA Practice Test 3 — 25 Questions

Question 1

When a manual change is made directly to a Kubernetes Service via 'kubectl edit', what behavior is expected from a properly configured GitOps operator set to 'Automatic Sync'?

Accepted Answer

The operator identifies the drift and automatically overwrites the live state with the Git version.. With Automatic Sync enabled, a GitOps operator such as Argo CD continuously compares live cluster state against the desired state in Git. When it detects drift — for example, a manual kubectl edit to a Service — it automatically re-applies the Git version, overwriting the manual change. This self-healing behaviour is the core guarantee of GitOps: Git remains the single source of truth.

Answer

The operator ignores the change to prevent production downtime.

Answer

The operator updates the Git repository to match the new manual change.

Answer

The operator prompts the administrator for manual approval before reverting.

Question 2

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 3

You are debugging a GitOps deployment. The controller shows 'OutOfSync' but the cluster seems to be running correctly. What is the most likely cause?

Accepted Answer

Manual changes were made to the live resource that weren't captured in Git.. An 'OutOfSync' status means the live cluster state diverges from the desired state declared in Git. If the cluster is running correctly, the most common cause is that someone made manual changes (kubectl edit, kubectl apply, or a hotfix) directly to the live resource, so the controller detects drift between Git and the cluster. The controller is functioning as designed by flagging the discrepancy.

Answer

The network latency to the Git server is too high.

Answer

The Git repository is empty.

Answer

The controller is broken.

Question 4

Which of the following is considered 'best practice' for GitOps repository structure?

Accepted Answer

Using a separate repository for environment configurations. Best practice for GitOps repository structure is to separate application source code from deployment configuration, and often to use separate repositories (or at least separate directories) for environment-specific configurations (dev, staging, prod). This separation enables independent promotion, access control, and rollback per environment, and prevents a change to one environment from inadvertently affecting another. Using a separate repository for environment configurations is a recognized best practice.

Answer

Storing source code and manifest files in the same directory

Answer

Keeping all configuration in a single root file

Answer

Committing binary files to the repo

Question 5

Which THREE are standard ways to implement GitOps with Helm?

Accepted Answer

Using a GitOps operator to trigger 'helm install'.. Option C is correct because GitOps operators such as Argo CD or Flux watch a Git repository and automatically trigger Helm operations like 'helm install' or 'helm upgrade' when the desired state changes, which is the core GitOps reconciliation loop. Option D is correct because storing the final rendered YAML manifests in Git is a valid GitOps pattern (often called 'rendered manifests' or 'last-mile' GitOps), where the cluster state is applied directly from committed YAML without Helm running in the cluster. Option E is correct because storing Helm values files in Git is a standard GitOps approach where the chart is referenced from a chart repository and the environment-specific values are version-controlled, allowing the operator to render and apply the release. Option A is not a GitOps implementation because running 'helm upgrade' manually is an imperative, human-driven action that bypasses Git as the single source of truth. Option B is not a complete GitOps implementation because storing only the chart source code without values, rendered manifests, or an automated operator does not provide the declarative, continuously reconciled deployment that GitOps requires.

Answer

Running 'helm upgrade' manually.

Answer

Only storing the chart source code.

Question 6

When managing multiple environments (dev/stage/prod) in one repository, which folder structure is generally considered best practice?

Accepted Answer

Using environment-specific folders.. Environment-specific folders (e.g., /dev, /stage, /prod) keep manifests for each environment isolated while sharing a single repository, enabling consistent promotion workflows and clear ownership. This structure lets GitOps tools like Argo CD or Flux target a specific path per environment without duplicating the entire repo. It also makes diffs between environments obvious and supports per-environment overlays (Kustomize) or values files (Helm).

Answer

Storing configurations in the application code folder.

Answer

Putting everything in a single root folder.

Answer

Using different Git repos for every single manifest.

Question 7

Which Argo CD feature allows you to manage multiple applications with shared configuration?

Accepted Answer

ApplicationSets.. ApplicationSets is the Argo CD controller that generates multiple Application resources from a single template combined with generators (List, Cluster, Git, Matrix, Merge, Pull Request). It is purpose-built for managing many applications that share configuration, such as one app per cluster or per tenant.

Answer

Sync Waves.

Answer

Application Projects.

Answer

Resource Hooks.

Question 8

Which of the following is NOT a benefit of the GitOps model?

Accepted Answer

Increased system performance.. GitOps is a deployment and operational model that uses Git as the single source of truth for declarative infrastructure and applications. Its primary benefits are improved auditability (every change is a Git commit), faster disaster recovery (the desired state can be reapplied from Git), and standardized deployment processes (consistent workflows across environments). Increased system performance is not a benefit of GitOps; performance depends on application design, resource allocation, and infrastructure, not on how deployments are managed.

Answer

Improved auditability.

Answer

Faster recovery from disasters.

Answer

Standardized deployment processes.

Question 9

In a GitOps environment using Argo CD, what is the primary purpose of the reconciliation loop?

Accepted Answer

To automatically apply changes from the Git repository to the target Kubernetes cluster.. Argo CD's reconciliation loop continuously compares the desired state in Git with the live state in the cluster and, when auto-sync is enabled, applies the differences to bring the cluster into the desired state. This is the core mechanism that makes Git the source of truth for deployments.

Answer

To perform unit testing on manifest files before they are merged.

Answer

To push new container images to the registry whenever a build completes.

Answer

To scale deployment replicas based on real-time traffic metrics.

Question 10

In a GitOps pattern, how do you manage a rollback when an application deployment fails?

Accepted Answer

Revert the commit in Git and let the GitOps operator reconcile.. In GitOps, Git is the single source of truth for the desired state of the system. To roll back a failed deployment, you revert the offending commit in Git, which changes the desired state back to the last known good version. The GitOps operator (e.g., Argo CD or Flux) continuously reconciles the cluster to match Git, so it will automatically apply the rollback. This approach ensures that the rollback is version-controlled, auditable, and consistent with the declarative model.

Answer

Delete the pods and let the operator recreate them.

Answer

Stop the GitOps operator to prevent it from correcting the state.

Answer

Run 'kubectl rollout undo' on the deployment.

Question 11

Which THREE of the following are valid ways to trigger a sync in a GitOps environment?

Accepted Answer

Pushing a commit to the Git repository. Option A is correct because in a GitOps model the Git repository is the single source of truth, so pushing a commit changes the desired state and the GitOps controller (e.g., Argo CD or Flux) detects the new revision and reconciles the cluster to match it. Option B is correct because GitOps tools such as Argo CD expose a manual 'Sync' action in their UI/dashboard that forces the controller to apply the current desired manifests immediately, regardless of the automatic polling interval. Option E is correct because Git providers like GitHub, GitLab, or Bitbucket can send webhook notifications to the GitOps controller's endpoint, letting it react instantly to repository events instead of waiting for the next poll cycle. Option C is not valid because SSH access to a node is an imperative administrative action that does not alter the Git-declared desired state and is not a GitOps sync trigger. Option D is not valid because restarting the Kubernetes API server is an infrastructure operation that does not change or re-read the Git source of truth and is unrelated to triggering reconciliation.

Answer

Logging into the node via SSH

Answer

Restarting the Kubernetes API server

Question 12

You are debugging an ArgoCD sync failure. You find the 'Sync Status' is 'Failed'. Where is the most detailed error information located?

Accepted Answer

Sync Result in Application UI. The Sync Result in the Application UI provides the most detailed error information for a failed sync. It shows the exact error message from the sync operation, including which resource failed, the reason (e.g., validation error, conflict, or apply failure), and often the full output from kubectl apply. This is the primary place to diagnose sync failures because it aggregates the results of the sync attempt.

Answer

ApplicationSet status

Answer

Git log

Answer

ArgoCD repo server logs

Question 13

Which TWO of the following best describe the benefits of adopting GitOps?

Accepted Answer

Better auditability through a full history of changes in Git.. Option A is correct because GitOps stores all desired-state manifests in Git, so every change is a versioned commit with author, timestamp, and diff, giving a complete, immutable audit trail of who changed what and when. Option B is correct because GitOps controllers such as Argo CD or Flux continuously reconcile the live cluster against the declarative state in Git, detecting and correcting drift so the cluster converges on the committed desired state. Option C is wrong because GitOps does not bypass testing; CI pipelines still run tests and validation before changes are merged and synced. Option D is wrong because GitOps reduces manual operator intervention through automated reconciliation rather than increasing dependence on it. Option E is wrong because GitOps still relies on container images pulled from a registry; Git holds the manifests, not the image layers.

Answer

Higher speed because testing is bypassed.

Answer

Increased dependence on manual operator intervention.

Answer

The ability to run without any container registry.

Question 14

What is the relationship between the 'desired state' and the 'actual state' in GitOps?

Accepted Answer

The controller continuously reconciles the actual state to the desired state.. In GitOps, Git holds the declarative desired state, and a controller (e.g., Argo CD or Flux) continuously compares it against the live actual state, reconciling any differences so the cluster converges on Git. This continuous reconciliation loop is the defining mechanism of GitOps.

Answer

The desired state is defined by the actual state.

Answer

The desired state is enforced by the controller to match the actual state.

Answer

The actual state is manually pushed to the desired state.

Question 15

Which TWO of the following are benefits of using Git as the 'Source of Truth'?

Accepted Answer

Clear audit trail of who changed what and when. Option A is correct because Git records every commit with author identity, timestamp, and a cryptographic hash of the exact changes, giving an immutable, reviewable history of who changed what and when — the essence of an audit trail for a source of truth. Option B is correct because Git's versioned history lets you undo a bad change deterministically with commands like git revert (which creates a new commit that inverts a prior one) or git reset, enabling reliable rollback to a known-good state. Option C is wrong because Git is a version-control system for code and configuration, not a cloud IAM or account-lifecycle tool; it cannot detect or delete unused cloud accounts. Option D is wrong because Git reduces reliance on manual terminal access by providing a structured, reviewable workflow (commits, branches, pull requests) rather than encouraging ad-hoc manual changes. Option E is wrong because Git has no bearing on application CPU performance; it manages source history, not runtime compute resources.

Answer

Automatic removal of unused cloud accounts

Answer

Increased reliance on manual terminal access

Answer

Faster CPU performance for applications

Question 16

In a GitOps workflow, what is the best way to handle a configuration that must be different for production versus development clusters?

Accepted Answer

Kustomize overlays. Kustomize overlays let you maintain a single base set of manifests and apply environment-specific patches (replica counts, resource limits, image tags, ConfigMaps) via overlays for dev, staging, and prod. This keeps configuration DRY, reviewable in Git, and avoids drift, which is exactly what GitOps requires. ArgoCD and Flux both natively support Kustomize, making overlays the canonical pattern for environment differentiation.

Answer

Copy-pasting the manifest files

Answer

Using environment variables

Answer

Running multiple ArgoCD instances

Question 17

Which TWO of the following are primary benefits of storing immutable state in Git?

Accepted Answer

Reduction in manual cluster configuration errors. Option A is correct because storing immutable state in Git (the GitOps model) makes the desired cluster configuration declarative and version-controlled, so changes are reviewed and applied consistently, which reduces manual, error-prone cluster configuration. Option D is correct because every change to the desired state is a Git commit, giving a complete, auditable history of who changed what and when, enabling rollback and traceability of all environment changes. Option B is not a primary benefit of immutable Git state, since hotfix speed depends on the CI/CD pipeline and deployment process, not on storing state in Git. Option C is incorrect because Git does not automatically convert Docker images into YAML manifests; that requires separate tooling. Option E is incorrect because Git stores configuration, not server storage capacity, so it does not increase server-side storage.

Answer

Faster deployment of hotfixes directly to production

Answer

Automated conversion of Docker images to YAML

Answer

Increased server-side storage capacity

Question 18

You are managing secrets using SOPS with Age. You notice that Flux cannot decrypt the files. What is the most likely cause?

Accepted Answer

Missing private key secret in the flux-system namespace. Flux's kustomize-controller and helm-controller perform SOPS decryption in-cluster using the Age private key, which must be present as a Kubernetes Secret named 'sops-age' in the flux-system namespace (referenced via the decryption.secretRef field). If that Secret is missing or the key doesn't match the Age recipient used to encrypt the files, Flux logs 'failed to decrypt' errors and reconciliation fails. SOPS version, network latency, and git branch have no bearing on the in-cluster decryption step.

Answer

SOPS version mismatch

Answer

Network latency

Answer

Incorrect git branch

Question 19

Which TWO of the following are characteristics of a 'GitOps Operator'?

Accepted Answer

It runs inside the Kubernetes cluster. Option C is correct because a GitOps Operator is deployed as a controller inside the Kubernetes cluster, where it watches custom resources and continuously manages the desired state of the environment. Option E is correct because the core function of a GitOps Operator is to observe the live cluster state, compare it against the desired state declared in Git, and act to reconcile any drift automatically. Options A, B, and D are incorrect: a GitOps Operator is not merely an external monitoring tool, it does not generate application source code, and it does not require manual triggers for every update since reconciliation is continuous and automated.

Answer

It is a purely external monitoring tool

Answer

It generates application source code

Answer

It requires manual triggers for every update

Question 20

Which of these is a typical 'Desired State' artifact in GitOps?

Accepted Answer

A Kubernetes YAML manifest.. In GitOps, the desired state is the declarative configuration that defines how the system should look. A Kubernetes YAML manifest is a canonical example: it declares resources like Deployments, Services, and ConfigMaps. This manifest is stored in Git and used by GitOps operators to reconcile the live cluster.

Answer

An audit log from the cluster.

Answer

A shell script that installs software.

Answer

A live running container.