CGOA Practice Test 23 — 15 Questions

Question 1

What is the most effective approach to handle 'secrets' in GitOps when you require strict compliance that mandates secrets never exist in plain text in the repo?

Accepted Answer

Use an external secret store that injects values into the cluster at runtime.. For strict compliance that mandates secrets never exist in plain text in the repo, the most effective approach is an external secret store (e.g., HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) that injects values into the cluster at runtime via an operator like External Secrets Operator or Secrets Store CSI Driver. The Git repo only contains references (e.g., ExternalSecret CRs), never the secret material itself, satisfying the compliance requirement.

Answer

Store secrets in an encrypted cloud storage bucket and manually map them.

Answer

Use standard Kubernetes secrets and hope for the best.

Answer

Use Sealed Secrets with a public key in Git.

Question 2

Which THREE items should be excluded from a GitOps repository?

Accepted Answer

Container images (binaries).. Option A (Container images/binaries) is correct because GitOps repositories should hold declarative configuration and source, not large binary artifacts; container images belong in a container registry (e.g., Docker Hub, ECR, GCR) referenced by immutable digest or tag, since storing binaries bloats the repo and breaks Git's text-diff/versioning model. Option B (Plaintext passwords/API keys) is correct because committing secrets exposes them permanently in Git history and violates security best practices; secrets should be managed via a secrets manager (e.g., HashiCorp Vault, AWS Secrets Manager, Sealed Secrets, SOPS) and injected at runtime. Option C (Ephemeral cache files) is correct because transient artifacts like build caches, node_modules, or .terraform directories are machine-generated, non-deterministic, and should be excluded via .gitignore since they are not part of the desired state and cause noisy diffs. Option D (Rendered Kubernetes YAML) is not excluded because rendered manifests are often exactly what a GitOps tool such as Argo CD or Flux reconciles against the cluster, representing the desired declarative state. Option E (Documentation files) is not excluded because README, runbooks, and architecture docs are valuable, human-readable content that belongs alongside the configuration in the repository.

Answer

Rendered Kubernetes YAML.

Answer

Documentation files.

Question 3

Which THREE of the following are common components of a GitOps platform?

Accepted Answer

CI Pipeline (e.g., GitHub Actions). A GitOps platform typically includes a CI pipeline such as GitHub Actions (option A), which builds, tests, and produces the immutable artifacts (container images, manifests) that the GitOps workflow then deploys. The Git repository (option C) is the declarative source of truth: it stores the desired state of the cluster, and every change is made via commits and pull requests rather than direct kubectl commands. The GitOps operator (option E), such as Argo CD or Flux, runs inside the cluster, continuously reconciles the live state against the repository, and reports or auto-corrects drift. An external load balancer (option B) is an infrastructure/routing component, not a defining part of a GitOps platform, and a manual deployment script (option D) contradicts GitOps' declarative, automated, pull-based reconciliation model.

Answer

External Load Balancer

Answer

Manual Deployment Script

Question 4

How does GitOps help with disaster recovery?

Accepted Answer

You can restore the entire cluster state by pointing a new cluster to the Git repository.. GitOps aids disaster recovery by allowing you to restore the entire cluster state by pointing a new cluster to the Git repository. Since Git holds the declarative desired state, a new cluster can be provisioned and synced to match that state, enabling rapid recovery.

Answer

It prevents the disaster from happening in the first place.

Answer

It automatically buys new hardware.

Answer

It keeps a copy of your data in the Git repo.

Question 5

Which THREE of the following are common tasks performed by a GitOps Operator? (Choose three)

Accepted Answer

Applying configurations to the cluster to resolve detected drift.. Option A is correct because a GitOps Operator continuously reconciles the cluster by applying the desired configuration from Git whenever it detects drift between the live state and the declared state. Option C is correct because the operator's core reconciliation loop compares the actual cluster state against the desired state stored in Git to determine whether any action is needed. Option E is correct because the operator continuously monitors the Git repository (e.g., via polling or webhooks) for new commits so it can pull and apply updated manifests. Option B is not a GitOps Operator task, since unit testing of manifests is a CI/development activity rather than runtime reconciliation. Option D is also not a GitOps Operator task, because building and pushing container images belongs to a CI pipeline (e.g., Jenkins, GitHub Actions), not to the operator that syncs cluster state.

Answer

Generating unit tests for Kubernetes manifests.

Answer

Building and pushing new Docker images to a registry.

Question 6

You are troubleshooting a Flux installation. The operator is failing to pull updates from a private GitHub repository. What component is most likely misconfigured?

Accepted Answer

The GitRepository secret. Flux uses a GitRepository custom resource to define the source repository, including the URL, branch, and authentication secret. If the operator cannot pull updates from a private GitHub repository, the most likely misconfiguration is the GitRepository secret — the credentials (e.g., SSH key or token) referenced by the GitRepository are incorrect, missing, or lack permissions.

Answer

The Helm chart version

Answer

The cluster service account permissions

Answer

The Kustomization path

Question 7

What does the 'prune' setting in a GitOps controller do?

Accepted Answer

Automatically deletes resources from the cluster that are no longer in Git. The prune setting in a GitOps controller instructs it to delete live cluster resources that are no longer declared in Git. When enabled, if a manifest is removed from the repository, the controller will remove the corresponding object from the cluster during the next sync, keeping the cluster an exact mirror of Git. Without pruning, deleted manifests leave orphaned resources running indefinitely, causing drift and resource leakage.

Answer

Removes unused Git branches

Answer

Trims logs to save disk space

Answer

Limits the number of replicas

Question 8

Which THREE of the following are essential components of an effective GitOps 'Continuous Drift Detection and Correction' strategy?

Accepted Answer

Continuous comparison loop between cluster live state and Git desired state. Option A is correct because drift detection fundamentally requires a continuous reconciliation loop that compares the cluster's live state against the desired state declared in Git, which is the core mechanism tools like Argo CD and Flux use. Option B is correct because detecting drift is only useful if it triggers an action — either an alert to operators or automated synchronization (self-heal) to bring the cluster back in line with Git. Option C is correct because strict RBAC and admission controls that prevent manual, out-of-band changes to the cluster reduce drift at its source and preserve Git as the single source of truth. Option D is not correct because periodic manual audits are reactive and point-in-time, not continuous, so they cannot satisfy a continuous drift detection strategy. Option E is not correct because a CI-based push pipeline applies changes only when the pipeline runs, rather than continuously reconciling live state against Git as a pull-based GitOps agent does.

Answer

Regular manual audits of the cluster state

Answer

Using a CI-based push pipeline to update the cluster

Question 9

In the context of 'Configuration as Code', why is it considered a best practice to use a declarative manifest format (like YAML) rather than imperative commands?

Accepted Answer

Declarative manifests represent the desired state, allowing for automated drift detection and reconciliation.. Declarative manifests like YAML are preferred because they express the desired end state of the system, enabling the GitOps controller to continuously compare actual state to desired state, detect drift, and automatically reconcile. This is the foundation of GitOps' self-healing and auditability. Imperative commands, by contrast, describe steps to execute and leave no persistent desired-state record for reconciliation.

Answer

It is easier to type YAML than complex CLI commands.

Answer

YAML files are automatically encrypted by the GitOps provider.

Answer

Imperative commands are not supported by the Kubernetes API.

Question 10

Which THREE of the following are essential security practices for GitOps? (Select three)

Accepted Answer

Strict RBAC for both the Git repository and the Kubernetes cluster.. Option B is correct because GitOps relies on Git as the single source of truth, so strict RBAC must be applied both to the Git repository (to control who can merge manifest changes) and to the Kubernetes cluster (to limit what the GitOps controller and users can do), preventing unauthorized or overly privileged changes. Option C is correct because OPA Gatekeeper acts as a Kubernetes admission controller that enforces policies (via ConstraintTemplates and Constraints) on manifests before they are applied, ensuring deployed resources comply with organizational security rules. Option D is correct because secrets stored in Git must be encrypted beforehand, for example with SOPS (often combined with age or KMS), since Git history is persistent and plaintext secrets would be exposed to anyone with repository read access. Option A is not appropriate because granting every developer direct cluster-admin access violates least privilege and bypasses the controlled GitOps workflow. Option E is not appropriate because sharing a Git repository password with all cluster users destroys accountability and violates the principle of unique, least-privilege credentials.

Answer

Giving every developer direct 'cluster-admin' access.

Answer

Sharing the Git repository password with all cluster users.

Question 11

Which of the following is a core principle of GitOps?

Accepted Answer

The system state is defined in a version-controlled repository.. A core principle of GitOps is that the desired state of the system is declaratively defined and stored in a version-controlled repository (like Git). This repository acts as the single source of truth, and automated tools continuously reconcile the actual state to match it. This enables versioning, auditing, and rollback capabilities.

Answer

Manual intervention is required to scale deployments.

Answer

Developers should have direct 'cluster-admin' access.

Answer

The system state is defined by the latest CI pipeline execution.

Question 12

Which TWO of the following are key features of the Flux Kustomization controller?

Accepted Answer

Reconciling Kubernetes manifests. Option A is correct because the Flux Kustomization controller's core job is to reconcile Kubernetes manifests from a source (such as a GitRepository or OCIRepository) into the cluster, applying them and continuously correcting drift to match the desired state. Option C is correct because Flux Kustomization supports post-build variable substitution, where placeholders like ${VAR} in the manifests are replaced using values from ConfigMaps/Secrets referenced in the spec.postBuild.substituteFrom field before the resources are applied. The unmarked options do not belong: Flux has no direct Jenkins integration (B), it does not host a private Git server (D) — it only consumes sources via GitRepository/OCIRepository — and it does not manage container image build pipelines (E), which is the role of tools like Tekton or CI systems rather than the Kustomization controller.

Answer

Direct integration with Jenkins

Answer

Hosting a private Git server

Answer

Managing container image build pipelines

Question 13

What is the primary role of an 'Immutable' state in a GitOps repository?

Accepted Answer

To ensure that historical configurations can be reliably rolled back.. In GitOps, an immutable repository state means that once a configuration is committed, it is never modified in place — changes are made by creating new commits. This immutability provides a reliable audit trail and ensures that any historical configuration can be deterministically rolled back by checking out a previous commit. It is a core principle that enables reproducibility and disaster recovery in GitOps workflows.

Answer

To increase the storage capacity of the cluster.

Answer

To allow the cluster to delete resources at will.

Answer

To force developers to use a specific IDE.

Question 14

In the context of a CI/CD pipeline, where does the 'GitOps' bridge typically occur?

Accepted Answer

When the CI pipeline updates the manifest repository with the new image tag.. The GitOps bridge in a CI/CD pipeline occurs when the CI pipeline completes building and testing, then updates the manifest repository (e.g., a Git repo containing Kubernetes YAML) with the new image tag. This triggers the GitOps operator to reconcile the cluster to the new desired state.

Answer

When the operator triggers the build.

Answer

When the developer logs into the cluster.

Answer

When the Git repo is deleted.

Question 15

Why does GitOps encourage the use of small, frequent commits?

Accepted Answer

To reduce the blast radius and simplify troubleshooting.. Small, frequent commits limit how many resources change in a single deployment, shrinking the blast radius if something breaks and making it easier to identify which commit introduced a problem. This aligns with GitOps principles of traceability and fast rollback via git revert.

Answer

To force developers to spend more time on documentation.

Answer

To ensure the Git server doesn't crash.

Answer

To minimize the size of the Git repository.