CGOA Practice Test 15 — 15 Questions

Question 1

What is an 'Image Updater' in the GitOps ecosystem?

Accepted Answer

A controller that updates image tags in Git. An Image Updater in GitOps is a controller that monitors container registries for new image versions and automatically updates the corresponding image tags in Git repositories. This ensures that the desired state in Git reflects the latest available images, enabling automated deployments through GitOps workflows. Tools like Argo CD Image Updater and Flux's Image Automation Controller implement this pattern by committing changes to Git, which are then synced to the cluster.

Answer

A tool to compress images

Answer

A tool to clean up old images in the registry

Answer

A tool to scan images for vulnerabilities

Question 2

What is the impact of having multiple GitOps operators in the same cluster?

Accepted Answer

It leads to potential race conditions and configuration conflicts. Running multiple GitOps operators (e.g., two Argo CD instances or Argo CD plus Flux) against the same cluster means each operator independently reconciles resources toward its own declared desired state. When both manage overlapping resources, they will continuously overwrite each other's changes, producing race conditions, flapping resource states, and configuration conflicts. GitOps assumes a single source of truth per resource, so multiple controllers violate that model rather than improving it.

Answer

It is the recommended setup for high availability

Answer

It automatically distributes the load across nodes

Answer

It increases the throughput of deployments

Question 3

Your team is using a pull-based GitOps pattern. Which component is responsible for initiating the communication to the Git repository to check for updates?

Accepted Answer

The agent running inside the Kubernetes cluster.. In a pull-based GitOps model, an agent (such as Argo CD or Flux) runs inside the Kubernetes cluster and periodically polls the Git repository to detect desired-state changes. The agent initiates the outbound connection to Git, then reconciles the cluster state to match what is declared in the repository. This pull model keeps cluster credentials out of the CI system and gives the cluster control over when updates are applied.

Answer

The developer's local kubectl client.

Answer

The CI/CD pipeline pushes updates to the cluster.

Answer

The Git server pushes changes to the cluster webhook.

Question 4

You are implementing a GitOps pipeline for a complex microservices architecture. To satisfy the principle of 'versioned and immutable state', how should you handle environment-specific configurations while maintaining a single source of truth?

Accepted Answer

Use Kustomize overlays to manage environment-specific patches stored in the same repository. Kustomize overlays allow you to manage environment-specific configurations as patches stored in the same Git repository, maintaining a single source of truth while avoiding duplication. This aligns with GitOps principles of versioned and immutable state because all configurations are declarative, version-controlled, and can be reviewed. Overlays let you customize base manifests for dev, staging, and prod without branching or separate repos.

Answer

Use a CI pipeline to inject environment variables into the cluster via API calls

Answer

Execute helm install --set commands during the deployment phase

Answer

Maintain separate Git repositories for every environment

Question 5

In the context of GitOps, what is meant by 'Pull-based' architecture?

Accepted Answer

The cluster agent proactively pulls configurations from the repository.. In a pull-based GitOps architecture, an agent running inside the cluster (such as Argo CD or Flux) continuously monitors the Git repository for changes and pulls the desired state, applying it to the cluster. This is in contrast to push-based models where external systems push changes into the cluster. The cluster agent proactively pulls configurations, ensuring the cluster state converges to the declared state in Git.

Answer

The repository pulls changes from the cluster.

Answer

The cluster is pulled into the development network.

Answer

Developers push code to the cluster API.

Answer

External systems pull logs from the cluster.

Question 6

You are configuring an automated GitOps pipeline. How do you prevent 'drift' from occurring due to out-of-band changes?

Accepted Answer

By enabling automated self-healing in the GitOps controller.. Automated self-healing in the GitOps controller continuously reconciles the live cluster state against the desired state stored in Git. When an out-of-band change (drift) is detected, the controller automatically reverts the cluster to match Git, preventing drift from persisting. This is a core GitOps principle: the controller enforces the declared state.

Answer

By manually disabling 'kubectl' access for all users.

Answer

By storing the state in a central database instead of Git.

Answer

By setting up a cron job to restart the cluster daily.

Question 7

Which TWO of the following are common pitfalls when integrating DevSecOps into a GitOps pipeline?

Accepted Answer

Skipping vulnerability scans for Kubernetes manifests.. Option B is correct because Kubernetes manifests (YAML) can embed insecure configurations such as privileged containers, hostPath mounts, or images with known CVEs, and if the GitOps pipeline only validates application code but never scans the manifests, these misconfigurations reach the cluster unchecked. Option D is correct because Git stores full history, so committing plaintext secrets (passwords, tokens, kubeconfigs) exposes them to anyone with repo read access and they persist even after deletion unless history is rewritten; secrets should instead be managed via Sealed Secrets, External Secrets Operator, or a vault. Option A is not a DevSecOps pitfall per se — multiple branches are a normal Git workflow (though long-lived branches can cause drift, that is a GitOps hygiene issue, not a security pitfall). Option C is not a pitfall but a core GitOps practice, since an automated reconciliation operator (e.g., Argo CD or Flux) is what enforces the desired state. Option E is also not a pitfall — automating deployment of code changes is the fundamental purpose of a GitOps pipeline.

Answer

Using multiple branches in Git.

Answer

Setting up an automated reconciliation operator.

Answer

Automating the deployment of code changes.

Question 8

Which THREE components are essential for a robust pull-based GitOps deployment?

Accepted Answer

A Git repository hosting declarative manifests.. Option A is correct because a pull-based GitOps workflow requires a Git repository that stores the declarative manifests (YAML/Helm/Kustomize) representing the desired state of the system, which serves as the single source of truth. Option B is correct because a Kubernetes cluster is the target runtime environment where the applications defined in those manifests are actually deployed and reconciled. Option C is correct because a GitOps controller such as Argo CD or Flux runs inside the cluster, continuously pulls the desired state from Git, and reconciles it against the live cluster state. Option D is not essential and is in fact contrary to the pull model, since a CI server with cluster-admin access implies a push-based deployment and violates least-privilege principles. Option E is not required because the cluster state is stored in etcd and the desired state in Git; no dedicated external database is needed for GitOps.

Answer

A continuous integration server with cluster-admin access.

Answer

A dedicated database for storing cluster state.

Question 9

If you have a multi-cluster setup and you want to ensure that 'production' clusters only pull images from a hardened internal registry, how can you enforce this in GitOps?

Accepted Answer

Using Admission Controllers to enforce policy.. Admission controllers in Kubernetes can intercept requests to the API server before persistence and enforce policies, such as requiring images to come from a specific registry. In a GitOps workflow, you can deploy admission controllers like OPA Gatekeeper or Kyverno via Argo CD to enforce that only images from the hardened internal registry are allowed in production clusters. This provides a policy-as-code guardrail that cannot be bypassed by developers.

Answer

By changing the Argo CD global settings.

Answer

By hardcoding the registry URL in every pod manifest.

Answer

By updating the Git repository access permissions.

Question 10

Which TWO of the following are valid ways to configure an Argo CD 'Application'?

Accepted Answer

By applying a YAML manifest via kubectl. Option C is correct because an Argo CD Application is a Kubernetes custom resource (CRD) of kind Application in the argoproj.io API group, so it can be created or updated declaratively by applying a YAML manifest with kubectl (e.g., kubectl apply -f application.yaml). Option D is correct because the Argo CD CLI provides commands such as 'argocd app create' and 'argocd app set' that configure an Application through the Argo CD API server. Option A is incorrect because modifying the Argo CD binary is neither a supported nor a practical configuration method and would not define an Application resource. Option B is incorrect because bypassing the API server is not a valid configuration path; Argo CD Applications are managed through the Kubernetes API or Argo CD API. Option E is incorrect because deleting the Git repository removes the source of manifests and does not configure an Application.

Answer

By modifying the Argo CD binary code

Answer

By writing a shell script that bypasses the API server

Answer

By deleting the Git repository

Question 11

When using OPA Gatekeeper for policy enforcement, what resource is used to define the actual logic of the policy?

Accepted Answer

ConstraintTemplate. In OPA Gatekeeper, a ConstraintTemplate defines the Rego policy logic and the schema of the constraint's parameters. It is a cluster-scoped custom resource that, when created, causes Gatekeeper to generate a new CRD (the constraint kind). You then instantiate that kind as a Constraint to actually enforce the policy on selected resources. The ConstraintTemplate is where the actual policy logic lives.

Answer

AdmissionRule

Answer

GatekeeperConfig

Answer

PolicyDefinition

Question 12

Why should you avoid using 'latest' as a container image tag in GitOps?

Accepted Answer

It prevents the controller from knowing exactly what version is deployed.. The 'latest' tag is mutable — it can point to different image digests over time, so the Git manifest no longer uniquely identifies the running artifact. GitOps controllers like Argo CD and Flux reconcile desired state from Git; if the tag is 'latest', the controller cannot detect drift or guarantee that the deployed image matches the declared version, breaking reproducibility and auditability.

Answer

It causes the cluster to crash.

Answer

It's slower to pull.

Answer

It requires more storage space.

Question 13

In GitOps, what does 'Self-Healing' mean?

Accepted Answer

The controller replaces manual changes with the state from Git.. Self-healing in GitOps means the controller continuously reconciles the live cluster state against the desired state in Git and automatically reverts any manual or out-of-band changes. If someone edits a Deployment with kubectl, the controller detects the drift and restores the Git-declared state.

Answer

The cluster reboots itself if it runs out of memory.

Answer

The application restarts if a pod crashes.

Answer

The developer re-pushes the code to fix the bug.

Question 14

Which THREE of the following actions occur during an ArgoCD sync operation?

Accepted Answer

Comparing live state vs desired state. Option A is correct because an ArgoCD sync begins by comparing the live state of the cluster against the desired state stored in Git (the target revision), which determines what needs to change. Option D is correct because the sync operation then applies those differences to the cluster, using kubectl apply or server-side apply to reconcile resources to the desired manifests. Option E is correct because ArgoCD must fetch the latest manifests from the Git repository at the specified revision before it can render and apply them. Option B is not correct because ArgoCD performs a rolling or declarative update and does not delete all existing pods as part of a normal sync. Option C is not correct because ArgoCD deploys pre-built manifests and does not build or rebuild container images; image building is handled by CI pipelines.

Answer

Deleting all existing pods

Answer

Rebuilding the application image

Question 15

You are running Argo CD on a Kubernetes cluster. A developer reports that the argocd-application-controller repeatedly logs 'Failed to load target state: rpc error: code = Unknown desc = comparison error' for one Application, and the Application is stuck in the 'Unknown' health state. The cluster's outbound internet access is blocked, and the Application sources manifests from a private Git repository over HTTPS. Which component of Argo CD must you check first to resolve this?

Accepted Answer

The argocd-repo-server, because it is responsible for cloning the Git repository and generating the manifests, and it cannot reach the private repository.. The error indicates Argo CD cannot load the desired manifests from Git. The argocd-repo-server is the component that clones repositories and generates manifests, so blocked outbound access to the private Git repository will cause exactly this failure. Inspecting repo-server logs and connectivity is the correct troubleshooting step.

Answer

The argocd-application-controller, because it performs the actual Kubernetes API calls to apply resources and cannot connect to the API server.

Answer

The argocd-server, because it serves the web UI and API and must fetch the manifests on behalf of the controller.

Answer

The argocd-dex-server, because it provides authentication and the Application may be failing due to an expired token.