CGOA Practice Test 3 — 30 Questions

Question 1

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 2

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 3

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 4

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 5

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 6

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 7

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 8

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 9

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 10

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.

Question 11

Which term best describes the process of ensuring the live cluster matches the desired state stored in Git?

Accepted Answer

Syncing. Syncing is the GitOps term for the process of applying the desired state from Git to the live cluster so that the actual state matches the declared state. In Argo CD, a sync operation applies manifests; in Flux, reconciliation achieves the same. The question describes exactly this convergence process, making 'Syncing' the correct term.

Answer

Validation

Answer

Provisioning

Answer

Compilation

Question 12

Which TWO are examples of 'Drift' in a GitOps environment?

Accepted Answer

A manual update to a Deployment image via kubectl.. In GitOps, drift is any divergence between the desired state stored in Git and the actual state running in the cluster. Option B is correct because running kubectl to change a Deployment's image modifies the live cluster state outside of Git, so the actual state no longer matches the declared manifest, which is classic configuration drift. Option E is correct because editing a Service type directly in the cluster (e.g., changing ClusterIP to NodePort) also bypasses Git and creates a mismatch between the declared and observed state. Option A is not drift because a CPU spike is a transient runtime metric, not a configuration divergence from Git. Option C is not drift because a container crash is an application/runtime failure, not a change to the declared desired state. Option D is not drift because a new Git commit updates the desired state itself and is the normal GitOps change mechanism, not a divergence from it.

Answer

A temporary spike in CPU usage.

Answer

A container crashing due to a code bug.

Answer

A new Git commit.

Question 13

Which TWO of the following are features of progressive delivery in GitOps? (Select two)

Accepted Answer

Gradual traffic shifting between application versions.. Option A is correct because progressive delivery in GitOps is fundamentally about gradually shifting traffic between application versions—using techniques like canary releases or blue-green deployments—so that a new version receives only a small percentage of traffic initially and that share increases as confidence grows. Option C is correct because progressive delivery tightly couples traffic shifting with automated analysis of custom metrics (e.g., error rate, latency, or business KPIs); if those metrics breach defined thresholds, the rollout is automatically rolled back, which is a core GitOps progressive delivery capability. Option B is not a feature of progressive delivery—manually logging into pods is an ad-hoc, non-automated troubleshooting step that contradicts the automated, declarative nature of GitOps. Option D is incorrect because immediate deployment of all changes to the entire cluster is a big-bang release, the opposite of progressive delivery's incremental rollout. Option E is incorrect because removing health checks would eliminate the very signals progressive delivery relies on to validate a rollout and trigger automated rollback.

Answer

Manually logging into pods to check health.

Answer

Immediate deployment of all changes to the entire cluster.

Answer

Removing all health checks from the application.

Question 14

Which TWO of the following are valid strategies for promoting an application from staging to production in GitOps? (Select two)

Accepted Answer

Merging a pull request from a staging branch to a production branch.. Option C is correct because in GitOps the Git repository is the single source of truth, so promoting an application is done by merging a pull request from a staging branch into a production branch, which changes the desired state that the GitOps operator (e.g., Argo CD or Flux) then reconciles into the production cluster. Option E is correct because GitOps commonly uses a directory-per-environment layout (e.g., kustomize overlays or Helm values files), so updating the environment-specific values file in the production directory commits the new desired production configuration, which the GitOps controller detects and applies. Option A is not a valid promotion strategy because deleting and recreating the application discards state and is not a declarative Git-driven promotion. Option B is not valid because 'kubectl rollout undo' is an imperative manual rollback that bypasses Git and would be reverted by the GitOps reconciler. Option D is not valid because pushing directly to the cluster bypasses the CI/CD pipeline and Git, violating the core GitOps principle that all changes flow through Git.

Answer

Deleting the application and recreating it.

Answer

Running a 'kubectl rollout undo' command manually.

Answer

Bypassing the CI/CD pipeline by pushing directly to the cluster.

Question 15

In GitOps, what is the 'Source of Truth'?

Accepted Answer

The Git repository.. In GitOps, the Git repository is the single source of truth because it holds the declarative manifests that define the desired state of the entire system. All changes originate as commits, and the GitOps agent continuously reconciles the live cluster to match what is declared in Git. This makes Git the authoritative record, not the running cluster.

Answer

The running Kubernetes cluster.

Answer

The CI pipeline logs.

Answer

The container registry.

Question 16

Which of these is a valid 'GitOps' approach for multi-environment management?

Accepted Answer

Using separate directories or branches for different environments (e.g., /overlays/prod).. GitOps relies on declarative infrastructure stored in Git, and using separate directories or branches for each environment (e.g., /overlays/prod) is a standard pattern to manage multi-environment configurations. This approach allows environment-specific customizations (like replicas, resource limits, or image tags) while keeping the base configuration DRY, often implemented with tools like Kustomize or Helm. It also enables independent promotion and rollback per environment via Git commits.

Answer

Ignoring environments and deploying everything to one namespace.

Answer

Using a single folder for all environments and using a script to toggle them.

Answer

Deploying directly to production using kubectl.

Question 17

You are using Kustomize 'overlays' for environment promotion. If you need to add a specific label to all resources in production but not in staging, where should you define it?

Accepted Answer

In the 'overlays/production' kustomization.yaml file.. In Kustomize, overlays are used to customize base resources for different environments. To add a label only in production, you define it in the production overlay's kustomization.yaml using the 'commonLabels' or 'labels' field. This ensures the label is applied only to resources in that overlay.

Answer

In the global GitOps config map.

Answer

By modifying the manifest manually after deployment.

Answer

In the 'base' directory kustomization.yaml file.

Question 18

What is the primary benefit of version controlling your cluster manifests?

Accepted Answer

It allows you to track, audit, and revert cluster changes. Version controlling cluster manifests (e.g., YAML files for Kubernetes resources) provides a historical record of every change made to the desired state of the cluster. This enables tracking who changed what and when, auditing for compliance or troubleshooting, and reverting to a previous working state if a change causes issues. These capabilities are core to GitOps and infrastructure-as-code practices, where the manifest repository is the single source of truth for cluster configuration.

Answer

It allows you to host files on your local desktop

Answer

It replaces the need for a database

Answer

It speeds up node startup time

Question 19

An organization uses Argo CD to manage Kubernetes clusters. A developer manually modifies a Deployment's replica count via kubectl. Which mechanism in Argo CD ensures this manual change is identified as non-compliant with the GitOps repository?

Accepted Answer

Argo CD Application Controller's reconciliation loop. Argo CD's Application Controller runs a continuous reconciliation loop that periodically compares the desired state in Git with the live state in the cluster. When a developer manually changes a Deployment's replica count via kubectl, the controller detects the difference (OutOfSync) and, if auto-sync with self-heal is enabled, reverts the live resource to match Git. This is the core drift-detection mechanism in Argo CD.

Answer

Git repository webhook

Answer

Kubernetes admission controllers

Answer

Kubernetes Garbage Collector

Question 20

Which action should a developer take to deploy a new version of an application in a GitOps-based workflow?

Accepted Answer

Submit a pull request to the Git repository containing the configuration update.. In a GitOps workflow, Git is the single source of truth, so any change to application state — including a new version — must be expressed as a commit or pull request to the configuration repository. The CD controller then detects the change and reconciles the cluster. This makes the PR the correct deployment trigger, providing review, audit trail, and rollback via Git history.

Answer

Wait for the automated CI/CD tool to trigger a redeployment.

Answer

Run 'kubectl apply' from their local machine.

Answer

Log into the Argo CD dashboard and click 'Deploy'.