CGOA Hard Questions — 25 Difficult Questions

Question 1

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 2

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 3

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 4

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 5

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 6

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 7

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 8

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 9

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 10

A company transitions from a push-based CI/CD pipeline (using Jenkins) to a pull-based GitOps model (using Flux). What is the primary security architectural change regarding cluster access?

Accepted Answer

The CI server no longer requires cluster credentials. In a pull-based GitOps model, the in-cluster operator (Flux) pulls desired state from Git and applies it from inside the cluster. The CI server's only job is to build and push artifacts and commit manifest changes to Git — it never needs kubeconfig or cluster API credentials. This removes the long-lived cluster credentials that a push-based Jenkins pipeline required to run kubectl/helm against the cluster.

Answer

Git is no longer the source of truth

Answer

The cluster no longer requires an API server

Answer

The operator is now a push-based agent

Question 11

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 12

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 13

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 14

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 15

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 16

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 17

You are configuring Flux to manage a multi-tenant cluster. You need to ensure that specific namespaces only allow images from an internal registry. Which tool should you use to enforce this at admission time?

Accepted Answer

Kyverno. Kyverno is a Kubernetes-native policy engine that enforces rules at admission time via a validating (and mutating) admission webhook, making it the correct tool to restrict image registries per namespace. A Kyverno ClusterPolicy or Policy with a validate rule can match pods in specific namespaces and reject any image not sourced from the internal registry.

Answer

ArgoCD Notifications

Answer

Sealed Secrets

Answer

Flux Image Automation Controller

Question 18

Which THREE of these practices are essential to successfully transition from traditional CI/CD to GitOps?

Accepted Answer

Replacing imperative 'kubectl' commands with declarative manifest files.. Option B is correct because GitOps requires the desired state to be expressed declaratively in manifest files (YAML) rather than through imperative commands like 'kubectl apply' or 'kubectl edit', so the cluster state can be versioned and reproduced. Option C is correct because Git must serve as the single source of truth, meaning all environment and application configuration lives in Git repositories and any change is made via commits and pull requests, not directly on the cluster. Option D is correct because a GitOps agent (e.g., Argo CD or Flux) must continuously reconcile the live cluster state with the desired state stored in Git, typically using a pull-based model that detects drift and automatically corrects it. Option A is not correct because a manual deployment document in a wiki is not version-controlled, not machine-readable, and cannot drive automated reconciliation, which contradicts GitOps principles. Option E is not correct because adding manual approvals increases friction and human intervention, whereas GitOps emphasizes automated, auditable, and repeatable delivery driven by Git commits and CI checks.

Answer

Maintaining a manual 'deployment' document in a wiki.

Answer

Increasing the number of manual approvals in the CI pipeline.

Question 19

What is a 'GitOps Operator'?

Accepted Answer

A software agent that monitors Git and the cluster to maintain state alignment.. A GitOps operator is a software agent, such as Argo CD or Flux, that runs inside or alongside the cluster and continuously monitors both Git and the cluster to maintain state alignment. It reconciles the desired state defined in Git with the actual state in the cluster, automatically correcting drift. This agent-based reconciliation is the defining characteristic of GitOps.

Answer

A tool that converts YAML to JSON.

Answer

A database that stores configuration history.

Answer

A human user who manually pushes Git commits.

Question 20

Which THREE of the following are best practices for managing GitOps secrets?

Accepted Answer

Encrypt secrets using tools like SealedSecrets. Option B is correct because SealedSecrets encrypts secrets with a controller-held private key so the ciphertext can be safely committed to a Git repository and decrypted only inside the cluster, which fits GitOps' declarative, version-controlled workflow. Option C is correct because an external secret manager such as HashiCorp Vault keeps the actual secret material outside Git and injects it at runtime, so the repository stores only references or paths rather than sensitive values. Option D is correct because regularly rotating secrets according to security policies limits the blast radius of any leaked credential and is a core secrets-management control. Option A is wrong because sharing secrets in cleartext via team chat exposes them to logs, backups, and unauthorized members. Option E is wrong because base64 is merely an encoding, not encryption, so anyone with repository access can trivially decode the secrets.

Answer

Share secrets in cleartext via team chat

Answer

Store base64 encoded secrets in Git