CGOA Practice Test 10 — 10 Questions

Question 1

You are configuring an Argo CD application. After a developer manually modifies a Kubernetes Service via kubectl, the application status changes to 'OutOfSync'. Which GitOps principle is this monitoring process specifically identifying?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

Drift detection. When a developer edits a Service directly with kubectl, the live state diverges from the desired state in Git, and Argo CD flags the Application as OutOfSync. This is precisely drift detection: the continuous comparison between the cluster's actual state and the Git-declared state. Argo CD's application-controller polls or watches resources and computes a diff, surfacing any divergence as OutOfSync until reconciled.

Answer

Rollback recovery

Answer

Image promotion

Answer

Webhook integration

Question 2

Which of the following is a key advantage of using a 'pull' based GitOps model (like Flux or ArgoCD) over a 'push' based CI/CD pipeline?

Accepted Answer

Elimination of external cluster credentials in CI. In a pull-based GitOps model, the in-cluster agent (Flux or ArgoCD) runs inside the Kubernetes cluster and pulls the desired state from Git. Because the agent already has in-cluster credentials via its ServiceAccount, the CI system never needs kubeconfig or cluster-admin credentials to deploy — it only commits to Git. This dramatically shrinks the attack surface and removes the need to store long-lived cluster credentials in CI secrets.

Answer

Faster build times

Answer

Automatic unit testing

Answer

No need for Git

Question 3

Which THREE of the following are critical security considerations for a GitOps implementation?

Accepted Answer

Requiring GPG signing for commits. Option A is correct because requiring GPG signing for commits ensures that only authorized developers can push changes to the Git repository, which is the single source of truth in GitOps; unsigned or tampered commits could otherwise inject malicious manifests into the cluster. Option C is correct because implementing RBAC for the Git repository restricts who can read, write, or merge to the branches that the GitOps operator reconciles, preventing unauthorized changes that would be automatically deployed. Option D is correct because storing secrets in external stores like HashiCorp Vault keeps sensitive credentials out of Git, where they would be exposed in plaintext and replicated to every cluster that syncs the repository. Option B is not correct because hardcoded passwords in Kubernetes manifests are a security anti-pattern that leaks credentials into version control. Option E is not correct because granting the GitOps operator cluster-admin access by default violates least privilege and dramatically expands the blast radius of a compromised operator.

Answer

Using hardcoded passwords in Kubernetes manifests

Answer

Granting the GitOps operator cluster-admin access by default

Question 4

Which of these is the most suitable tool to use as the 'Git' component of GitOps?

Accepted Answer

A standard Git repository (e.g., GitHub, GitLab).. GitOps fundamentally relies on Git as the single source of truth for declarative infrastructure and application state, so a standard Git repository (GitHub, GitLab, Bitbucket, etc.) is the canonical 'Git' component. The repository stores manifests, Helm charts, and Kustomize overlays that an agent continuously reconciles against the live cluster.

Answer

A container registry.

Answer

A local text file on the cluster nodes.

Answer

A relational database.

Question 5

An administrator notices that the 'sync' status of an Argo CD application is 'Synced' but the health status is 'Degraded'. What does this indicate?

Accepted Answer

The application is correctly defined in Git but is failing at runtime. A 'Synced' sync status means the live cluster resources match the desired manifests in Git — there is no configuration drift. A 'Degraded' health status, however, is reported by Argo CD's health assessment (based on resource readiness, e.g., a Deployment with unavailable replicas or a Pod in CrashLoopBackOff) and indicates the workloads are not functioning correctly at runtime. Together they signal that the desired state was applied successfully but the application itself is failing.

Answer

The Argo CD controller has crashed

Answer

The Git repository is unreachable

Answer

Git and the cluster state are mismatched

Question 6

What is the primary function of an 'Operator' in the context of GitOps?

Accepted Answer

Automating the reconciliation process within the cluster. In GitOps, an Operator is a Kubernetes controller that extends the API with custom resources and continuously reconciles the cluster to match the declared desired state. It encodes operational knowledge — such as how to deploy, upgrade, back up, or failover an application — into software that runs inside the cluster. This automation of the reconciliation process is precisely what makes Operators central to GitOps workflows.

Answer

Hosting the Git repository

Answer

Writing application code

Answer

Executing SQL queries

Question 7

You are implementing a multi-environment strategy. Which Git branching strategy best supports GitOps?

Accepted Answer

Using dedicated directories for each environment within a single repository.. In GitOps, the desired state of each environment is stored declaratively in Git, and a controller (e.g., Argo CD or Flux) continuously reconciles the live state to match it. Using dedicated directories per environment within a single repository (e.g., /envs/dev, /envs/staging, /envs/prod) allows each environment to have its own manifests and configuration while sharing common base resources via Kustomize or Helm. This structure supports promotion workflows (e.g., merging changes from dev to staging to prod) and provides clear separation without the overhead of multiple repositories. It also aligns with the principle of a single source of truth for all environments, making it easier to audit and manage drift.

Answer

Deleting the Git repository after each deployment to prevent tampering.

Answer

Using a single 'main' branch that is pushed to all environments simultaneously.

Answer

Creating a new repository for every single deployment.

Question 8

You are architecting a multi-cluster deployment. What is the benefit of using an 'Operator' based architecture over a standard CI/CD Push approach in this context?

Accepted Answer

It removes the need to store sensitive cluster administrative credentials in an external CI/CD tool.. An Operator runs inside the cluster and continuously reconciles desired state from custom resources, so it can authenticate using its own in-cluster ServiceAccount rather than requiring an external CI/CD system to hold cluster-admin kubeconfig or tokens. This inverts the trust model: the CI pipeline only needs to commit manifests or trigger a CR, while the Operator performs privileged actions locally. It also enables pull-based GitOps workflows where the cluster fetches changes instead of an external tool pushing them.

Answer

It allows the CI pipeline to run faster by offloading deployment tasks.

Answer

It ensures that the Git repository is automatically updated with the latest cluster metrics.

Answer

It forces developers to use the CLI for all infrastructure changes.

Question 9

You are designing a multi-cluster deployment with Argo CD. You want to avoid defining 50 individual Application manifests. Which feature should you use?

Accepted Answer

Argo CD ApplicationSets.. Argo CD ApplicationSets use generators (cluster, Git, list, matrix) to template and produce many Applications from a single manifest, so you avoid writing 50 individual Application resources. A cluster generator can automatically create one Application per registered cluster, which is exactly the multi-cluster scaling need. This is the idiomatic Argo CD feature for fleet-wide deployments.

Answer

Helm subcharts.

Answer

Git submodules.

Answer

Kubernetes Custom Resource Definitions (CRDs).

Question 10

You are using ArgoCD and need to ensure that secret values stored in Git via Sealed Secrets are decrypted only within the target cluster. What component performs the actual decryption of a SealedSecret resource?

Accepted Answer

Sealed Secrets controller. The Sealed Secrets controller is the in-cluster component (deployed as a Kubernetes controller/operator) that holds the private key used to decrypt SealedSecret resources. When a SealedSecret CRD is applied, the controller watches for it, decrypts the encrypted payload using the cluster's private key, and creates a standard Kubernetes Secret that workloads can consume. This design ensures the asymmetric private key never leaves the target cluster, so Git only ever stores ciphertext.

Answer

GitOps CLI (kubeseal)

Answer

Kubernetes API Server

Answer

ArgoCD Application controller