CGOA Full-Length Exam Simulation

Question 1

Which TWO of the following are considered 'Anti-Patterns' in a GitOps workflow? (Choose two)

Accepted Answer

Storing sensitive secrets as plain text in the Git repository.. Option A is correct because committing secrets as plain text in Git exposes credentials to anyone with repository read access and permanently embeds them in Git history, violating GitOps' declarative, auditable, and secure source-of-truth model; secrets should instead be managed with tools like Sealed Secrets, SOPS, or an external secrets manager. Option C is correct because making manual changes directly to the production cluster creates configuration drift from the Git-declared desired state, breaking the core GitOps principle that Git is the single source of truth and that all changes flow through version control and automated reconciliation. Option B is not an anti-pattern; using branches (or directories) per environment is a legitimate, widely used GitOps repository strategy for separating prod and dev configurations. Option D is not an anti-pattern; automating deployment with a GitOps operator such as Argo CD or Flux is the intended practice, as it continuously reconciles cluster state with Git. Option E is not an anti-pattern; storing application manifests in a central repository is a standard GitOps pattern that provides a single, versioned source of truth for deployments.

Answer

Using a Git branch to represent a specific environment (e.g., prod vs dev).

Answer

Automating the deployment process using a GitOps operator.

Answer

Storing application manifests in a central repository.

Question 2

You need to ensure that no one can modify cluster resources manually. How can you implement this in a GitOps-mature organization?

Accepted Answer

Remove cluster-admin access from all users except the GitOps controller.. In a GitOps-mature organization, the GitOps controller is the only entity with write access to the cluster, and all changes flow through Git. Removing cluster-admin access from all users except the GitOps controller enforces this by preventing manual modifications, ensuring that the Git repository remains the single source of truth. This is a foundational security practice in GitOps.

Answer

Install a plugin that logs all kubectl commands.

Answer

Add a firewall rule to block kubectl.

Answer

Disable the Kubernetes API server.

Question 3

Which TWO of the following are NOT recommended in a GitOps workflow?

Accepted Answer

Manual changes via kubectl. Option B (Manual changes via kubectl) is NOT recommended in a GitOps workflow because GitOps requires the Git repository to be the single source of truth, and any out-of-band change made directly with kubectl creates configuration drift that the reconciliation controller will detect and revert, defeating the declarative model. Option C (Storing plain-text secrets in the repository) is NOT recommended because committing unencrypted credentials to Git exposes sensitive data to anyone with repository access and to the permanent Git history, violating security best practices; secrets should instead be managed with tools like Sealed Secrets, SOPS, or an external vault. By contrast, option A (Automated reconciliation of state) is a core GitOps principle, typically implemented by controllers such as Argo CD or Flux continuously comparing live cluster state to the desired state in Git. Option D (Using Git as a source of truth) is the foundational GitOps tenet, providing versioning, auditability, and rollback. Option E (Using pull requests for code changes) is recommended because it enables peer review, CI validation, and an auditable approval trail before changes are merged and deployed.

Answer

Automated reconciliation of state

Answer

Using Git as a source of truth

Answer

Using pull requests for code changes

Question 4

What is the primary role of a 'GitOps controller'?

Accepted Answer

To watch the repository and reconcile the cluster state. A GitOps controller (e.g., Argo CD's application controller or Flux's kustomize-controller) continuously watches the Git repository for the desired state and reconciles the live cluster to match it, detecting and correcting drift. It is the engine that closes the loop between declarative intent in Git and actual cluster state. Without it, GitOps is just version-controlled YAML with no enforcement.

Answer

To host the container registry

Answer

To generate user tokens

Answer

To manage Git branches

Question 5

You are managing a global cluster setup with GitOps. How do you handle configuration that must be identical across all clusters while allowing for regional variations?

Accepted Answer

Using a base-overlay structure where the base contains common settings and overlays contain regional variations.. A base-overlay structure (as implemented by Kustomize) lets you define shared configuration once in a base directory and layer cluster- or region-specific patches in overlays, so identical settings stay DRY while regional variations are expressed as targeted overrides. This is the canonical GitOps pattern for multi-cluster fleets because it keeps a single source of truth for common config and isolates divergence to small, reviewable overlay files.

Answer

Only having one cluster.

Answer

Duplicating the configuration for every cluster.

Answer

Using global variables in a shell script to modify manifests.

Question 6

A team is reviewing their deployment practices against OpenGitOps standards. Which THREE conditions are required to satisfy the 'Declarative Desired State' and 'Versioned and Immutable State' principles?

Accepted Answer

The target system's desired state is expressed in a software-interpretable, declarative format like YAML or JSON.. Option A is correct because the OpenGitOps 'Declarative Desired State' principle requires that the intended state of the system be expressed in a declarative, software-interpretable format such as YAML or JSON, so tooling can read and reconcile it automatically. Option B is correct because 'Versioned and Immutable State' requires the desired state to live in a version-controlled repository whose history is append-only, meaning changes are added as new revisions rather than overwriting or deleting prior ones. Option C is correct because each revision must be uniquely identifiable—typically by a Git commit SHA—and fully reproducible, so any past state can be reconstructed and audited. Option D does not belong because allowing live cluster state to override the repository breaks the single source of truth and the immutability of the declared desired state. Option E does not belong because manual shell scripts executed directly on production control plane nodes are imperative, unversioned, and non-reproducible, contradicting both principles.

Answer

Live cluster state is permitted to override repository configurations during peak traffic periods.

Answer

System changes are made by executing manual shell scripts directly on production control plane nodes.

Question 7

Which GitOps tool provides a dedicated CLI called 'argocd'?

Accepted Answer

ArgoCD. ArgoCD ships with a dedicated command-line interface called `argocd`, used to log in, manage applications, sync, and inspect cluster state. The CLI is a first-class part of the ArgoCD project and is documented alongside the web UI. This is a defining characteristic of ArgoCD among GitOps tools.

Answer

Kyverno

Answer

Flux

Answer

Helm

Question 8

What does the status 'OutOfSync' indicate in Argo CD?

Accepted Answer

The live resources are not identical to the Git manifests. In Argo CD, the 'OutOfSync' status indicates that the live state of the resources in the Kubernetes cluster does not match the desired state defined in the Git manifests. Argo CD continuously compares the two and flags any drift, allowing operators to detect and reconcile differences. This is a core part of GitOps: Git is the source of truth, and any deviation is considered out of sync.

Answer

The Git repository is empty

Answer

The application is running out of memory

Answer

The Argo CD server is offline

Question 9

When evaluating ArgoCD vs Flux, which TWO of the following are distinct advantages of using Flux?

Accepted Answer

Modular, controller-based architecture. Option D is correct because Flux is built as a set of independent Kubernetes controllers (source-controller, kustomize-controller, helm-controller, notification-controller), each with a single responsibility, which allows operators to install only the components they need and to scale or upgrade them independently — a modular design that contrasts with ArgoCD's more monolithic application-server model. Option E is correct because Flux natively reconciles multiple Git repositories through multiple GitRepository sources, each watched by its own Kustomization or HelmRelease, so a single Flux installation can continuously reconcile many repos without extra tooling. The unmarked options do not belong: A and B describe ArgoCD's strengths, since ArgoCD ships a built-in web UI with graphical RBAC management, whereas Flux is CLI/GitOps-centric and configures RBAC through Kubernetes manifests; C is also an ArgoCD feature, as ArgoCD provides visual sync waves and health status in its dashboard, while Flux expresses ordering via dependsOn and health checks rather than a graphical sync-wave view.

Answer

Built-in web-based graphical dashboard

Answer

RBAC managed via UI

Answer

Visual sync waves

Question 10

What is the recommended way to handle secrets in GitOps?

Accepted Answer

Use an encrypted secret operator like SealedSecrets.. SealedSecrets (and similar operators like SOPS, External Secrets) allow secrets to be safely stored in Git by encrypting them with a public key; only the controller in the cluster can decrypt them with its private key. This preserves GitOps principles—everything is declarative and version-controlled—while keeping plaintext secrets out of the repository. The sealed secret is safe to commit even to a public repo because it can only be decrypted by the target cluster's controller.

Answer

Commit them directly to the repo in a private branch.

Answer

Create them manually using kubectl.

Answer

Store them in base64 in Git.

Question 11

An organization is implementing GitOps across its infrastructure using Kubernetes and Flux. Which TWO statements accurately describe core characteristics of the 'Automated Pull-Based Reconciliation' principle?

Accepted Answer

Reconciliation automatically corrects drift when actual live cluster state deviates from desired Git state.. Option A is correct because automated pull-based reconciliation continuously compares the desired state declared in Git with the actual live state in the cluster and automatically remediates any drift, restoring resources to the declared configuration. Option C is correct because in the pull model an in-cluster agent such as Flux's source-controller/kustomize-controller periodically fetches (polls) the Git repository and applies changes, so no inbound connection to the cluster is needed. Option B is wrong because pull-based GitOps never has Git initiate inbound SSH connections to worker nodes; the cluster agent pulls from Git instead. Option D is wrong because the whole point of pull-based GitOps is that external CI systems do not need cluster administrative credentials, which stay inside the cluster. Option E is wrong because reconciliation is automated and continuous, not gated by manual human approval for each resource sync.

Answer

The Git repository initiates an inbound SSH connection to cluster worker nodes to push manifest updates.

Answer

Cluster administrative credentials must be stored inside external CI system secret stores.

Answer

Reconciliation requires direct human approval at the terminal for every individual resource sync.

Question 12

You are managing a GitOps repository that contains both application manifests and cluster-wide configurations. You want to ensure that changes to cluster-wide configurations are applied before application workloads during a sync. Which Argo CD feature should you use?

Accepted Answer

Sync waves with negative wave numbers for cluster-wide resources.. Sync waves are the correct feature for ordering resources during a sync. By assigning negative wave numbers to cluster-wide configurations, they are applied before application workloads that have higher wave numbers. This ensures that dependencies are satisfied and avoids race conditions, which is a common GitOps pattern for managing complex deployments.

Answer

Argo CD Projects to group cluster-wide configurations and applications separately.

Answer

ApplicationSets with a progressive sync strategy.

Answer

Resource hooks with a PreSync phase for cluster-wide configurations.

Question 13

What is the purpose of the 'SealedSecrets' custom resource?

Accepted Answer

Encrypting sensitive data for Git storage. SealedSecrets is a Kubernetes controller that encrypts Secret manifests with a cluster-specific public key so the ciphertext can be safely committed to Git. Only the controller in the target cluster, holding the private key, can decrypt the SealedSecret back into a regular Secret. This enables GitOps workflows where secrets live in version control without exposing plaintext.

Answer

Backing up Kubernetes secrets

Answer

Managing cluster-wide RBAC

Answer

Encrypting traffic between pods

Question 14

Which TWO tools are commonly associated with the 'GitOps' ecosystem?

Accepted Answer

Argo CD.. Argo CD (D) is a declarative, GitOps continuous-delivery controller for Kubernetes that continuously reconciles the live cluster state against manifests stored in a Git repository, making it a flagship GitOps tool. Flux (E) is likewise a CNCF GitOps toolkit that watches Git repositories and applies/reconciles Kubernetes manifests, so it is equally central to the GitOps ecosystem. Docker Desktop (A) is a local container build/run environment, Nginx (B) is a web server/reverse proxy, and Prometheus (C) is a metrics monitoring and alerting system; none of these implement Git-based declarative reconciliation, so they are not GitOps tools.

Answer

Docker Desktop.

Answer

Nginx.

Answer

Prometheus.

Question 15

In a GitOps environment, what is the best strategy for managing external dependencies (like Helm charts)?

Accepted Answer

Pinning the version of the Helm chart in your Git repository.. Pinning the Helm chart version in Git ensures the exact chart revision is declared as code, so the GitOps operator reconciles a deterministic, reproducible state. This makes deployments idempotent, enables rollback by reverting the Git commit, and prevents an upstream chart maintainer from silently changing behaviour. Version pinning is the GitOps equivalent of locking dependencies in a package manager.

Answer

Always pulling the latest version from the remote Helm repository.

Answer

Ignoring the chart version and hoping it stays compatible.

Answer

Manually downloading the chart to every node.

Question 16

A developer pushes a change to Git, but the cluster does not update. Which log source is most effective for debugging the pull-based mechanism?

Accepted Answer

The logs of the GitOps controller (e.g., Argo CD repo-server or Flux controller).. The GitOps controller (Argo CD repo-server or Flux controller) is responsible for the pull-based reconciliation loop: it periodically fetches the desired state from Git, compares it to the live cluster state, and applies any differences. When a Git push does not result in a cluster update, the failure lies within this reconciliation process—such as an inability to fetch the repository, a manifest rendering error, or a sync policy misconfiguration. Therefore, the controller's logs are the most direct and effective source for diagnosing why the change was not applied.

Answer

The browser console of the user.

Answer

The application's logs inside the pod.

Answer

The Git provider's audit logs.

Question 17

A developer updates a Helm release values file in Git to change a ConfigMap key. How does the GitOps pull-based agent determine that reconciliation is necessary?

Accepted Answer

The agent continuously compares the target Git repository commit SHA and state against the cluster's actual state.. GitOps agents like Argo CD and Flux continuously compare the desired state defined by the target Git commit (SHA) against the actual state in the cluster. When the values file changes, the commit SHA changes, the rendered manifests differ, and the controller detects the divergence and triggers reconciliation to apply the new ConfigMap.

Answer

The container registry notifies the GitOps agent whenever a ConfigMap is altered in the source code.

Answer

The Kubernetes API server continuously queries the Git repository directly without using any controller.

Answer

The agent receives an SSH trigger sent manually by the developer from their workstation.

Question 18

When deploying across multiple clusters using Argo CD, you need to ensure that specific secrets are only available to clusters located in the 'us-east' region. Which resource should you use to enforce this segregation?

Accepted Answer

AppProject. AppProject is the Argo CD resource that provides logical grouping and multi-tenancy boundaries, including restricting which clusters, namespaces, and repositories a set of Applications may target. By defining a destination cluster allow-list scoped to the us-east region inside an AppProject, you enforce that only Applications bound to that project can deploy secrets to those clusters. This is the intended mechanism for segregating resources by region or environment.

Answer

ConfigMap

Answer

ApplicationSet

Answer

ClusterRoleBinding

Question 19

When configuring Kyverno policies to secure a cluster, which TWO of the following actions can a policy perform?

Accepted Answer

Enforce policies by blocking requests. Kyverno is a Kubernetes-native policy engine that operates as a validating and mutating admission controller, so option A is correct: a policy in Enforce mode causes the admission webhook to reject (block) any request that violates the rule, returning a denial to the API server. Option E is also correct: Kyverno policies can run in Audit mode, where violations are not blocked but are recorded as PolicyReports (and ClusterPolicyReports) that surface non-compliant resources for review. The remaining options are outside Kyverno's scope: provisioning new clusters (B) is done by tools like Cluster API, kubeadm, or Terraform; managing Git repository webhooks (C) belongs to Git hosting platforms or CI/CD systems such as GitHub/GitLab; and automatically upgrading cluster nodes (D) is handled by node lifecycle tooling like kubeadm upgrade, Cluster API, or managed-node upgrade features, not by a policy engine.

Answer

Provision new clusters

Answer

Manage Git repository webhooks

Answer

Automatically upgrade cluster nodes

Question 20

What does the term 'Self-Healing' mean in a GitOps context?

Accepted Answer

The system automatically restores the desired state if someone manually modifies the cluster. Self-healing in GitOps refers to the operator's ability to detect when the live cluster state diverges from the desired state stored in Git and automatically restore the desired state. If someone manually edits or deletes a resource, the operator reverts the change to match Git. This enforces Git as the single source of truth and prevents configuration drift.

Answer

The application automatically updates its own code

Answer

The cluster automatically reboots upon failure

Answer

The database automatically backs itself up