CGOA Practice Test 18 — 15 Questions

Question 1

Which TWO of the following are common GitOps challenges?

Accepted Answer

Drift between Git and live state. Option A is correct because a core GitOps challenge is configuration drift — the live cluster state diverging from the desired state declared in Git — which occurs when changes are made directly to the cluster (e.g., via kubectl) or when reconciliation fails, requiring continuous sync tools like Argo CD or Flux to detect and remediate it. Option D is correct because Git repositories are plaintext and version-controlled, so storing Kubernetes Secrets, credentials, and tokens directly in Git exposes sensitive data; teams must adopt solutions such as Sealed Secrets, SOPS, External Secrets Operator, or HashiCorp Vault to manage secrets securely. Option B is not a GitOps challenge because Git is the foundational prerequisite of GitOps — the entire model depends on a Git repository as the single source of truth, so its absence is a setup failure rather than a common operational challenge. Option C is not a GitOps-specific challenge because having many developers is a general team-scaling concern, and Git's branching, pull-request, and review workflows are specifically designed to handle large contributor bases. Option E is not a challenge because documentation volume is unrelated to GitOps mechanics; if anything, GitOps improves traceability through commit history and declarative manifests.

Answer

Lack of Git repository

Answer

Too many developers

Answer

Too much documentation

Question 2

What is the purpose of 'Image Tagging' in a GitOps workflow?

Accepted Answer

To ensure that the exact version of the application is deployed consistently.. Image tagging in a GitOps workflow provides a unique, immutable identifier for a specific version of a container image. By using a tag (e.g., a Git commit SHA or semantic version), you ensure that the exact same image is deployed consistently across environments and over time. This supports reproducibility and rollback.

Answer

To force the container to restart.

Answer

To track how many users are logged in.

Answer

To allow the container registry to delete old images.

Question 3

In a GitOps promotion pipeline, why is it recommended to tag container images with a unique Git commit SHA instead of 'latest'?

Accepted Answer

To ensure immutability and auditability.. Tagging container images with a unique Git commit SHA ensures immutability because the tag directly corresponds to a specific commit, making it easy to trace back to the exact source code. This provides auditability, as you can always identify which code version is running. Using 'latest' is mutable and can lead to inconsistent deployments.

Answer

Because the container registry requires unique SHAs.

Answer

To reduce the size of the container image.

Answer

Because 'latest' is deprecated by Docker.

Question 4

Your organization uses a 'Git-branch-per-environment' strategy. You notice that hotfixes applied to the 'production' branch are being overwritten by automatic merges from the 'staging' branch. Which GitOps promotion pattern should you adopt to prevent this drift?

Accepted Answer

Switch to a repository structure using Kustomize overlays with a single branch.. A single-branch repository with Kustomize overlays (B) separates environment-specific configuration (replicas, image tags, resource limits) into overlay directories while sharing a common base, so hotfixes applied to production are not overwritten by staging merges. Argo CD then syncs each overlay to its target cluster, eliminating branch-merge drift. This is the recommended GitOps promotion pattern for avoiding cross-branch overwrites.

Answer

Enable Argo CD 'automated.allowEmpty' sync options.

Answer

Implement an automated CI job to force push the staging branch to production.

Answer

Use Argo CD ApplicationSets with a 'git' generator to deploy only from the main branch.

Question 5

During an audit, an organization discovers that a secret was accidentally committed to a Git repository managed by Flux. An engineer deletes the commit containing the secret using 'git push --force' with a rewritten history. Why is this action problematic in a production GitOps environment?

Accepted Answer

Force-pushing history breaks the cryptographic chain of custody and can desynchronize agents expecting immutable, append-only history.. Force-pushing a rewritten history in a GitOps environment is problematic because it breaks the append-only, immutable history that GitOps agents rely on for cryptographic chain of custody and consistent reconciliation. Flux CD and similar tools expect the Git history to be immutable; rewriting it can cause agents to become desynchronized, as they may have already reconciled a commit that no longer exists, leading to unpredictable behavior.

Answer

Kubernetes secrets created before the force-push are automatically converted into ConfigMaps by the API server.

Answer

Flux automatically restores deleted Git commits by fetching missing objects from the live cluster memory.

Answer

Git repositories permanently reject future commits if a force-push is detected by the GitOps operator.

Question 6

You notice that your GitOps pipeline is stuck in a loop. What is the most likely cause?

Accepted Answer

The deployment process automatically commits changes back to the same Git branch that triggers the deployment.. A GitOps pipeline loop occurs when the deployment process writes changes back to the same Git branch that triggers the deployment, creating a feedback cycle where each sync generates a new commit that triggers another sync. This is common when tools like Argo CD or Flux are configured to update image tags or manifests in Git as part of the deployment. The fix is to separate the write-back branch or use a different mechanism like image updater with proper filters.

Answer

The cluster is too small.

Answer

The Git repository contains a circular reference.

Answer

The container registry is offline.

Question 7

You are auditing a GitOps process. Which of the following is an indicator that the process is NOT truly following GitOps principles?

Accepted Answer

An administrator manually updates a Kubernetes Deployment manifest directly on the cluster.. GitOps requires that the Git repository serves as the single source of truth for the desired state of the system, with all changes flowing through Git and being automatically reconciled by an operator. Option D describes a manual, out-of-band change directly to the cluster, which bypasses Git entirely and breaks the declarative, version-controlled workflow. This is a clear violation because the live state can drift from the declared state without any audit trail or reconciliation trigger.

Answer

Secrets are encrypted in the Git repo.

Answer

The cluster automatically reconciles changes pushed to Git.

Answer

Developers use PRs to propose changes to the environment.

Question 8

Which THREE of the following are benefits of the 'App-of-Apps' pattern? (Select three)

Accepted Answer

It enables hierarchical synchronization of applications.. Option A is correct because the App-of-Apps pattern in Argo CD uses a parent Application whose manifests define child Applications, so syncing the parent cascades sync/health to the children, enabling hierarchical synchronization. Option C is correct because the parent Application can aggregate child Application manifests organized by project or business unit, letting teams scope RBAC, sync waves, and ownership per grouping. Option D is correct because a single root Application manages many child Applications declaratively, drastically reducing the manual effort of creating and tracking large fleets of Applications. Option B is not correct because App-of-Apps only orchestrates Application resources; it does not enforce a single image tag across workloads. Option E is not correct because container registries are still required to store and pull images regardless of how Applications are structured.

Answer

It ensures all applications use the exact same image tag.

Answer

It eliminates the need for container registries.

Question 9

You are migrating a legacy application deployment process to GitOps. The application requires a specific sequence of database migrations to run before the new container version is deployed. How do you implement this in a GitOps-friendly way?

Accepted Answer

Use a Kubernetes 'Job' resource that runs before the Deployment, and manage dependencies with initContainers or Helm hooks.. In GitOps, all changes must be declarative and reconciled from Git. A Kubernetes Job resource (or Helm pre-install/pre-upgrade hook) declared in Git runs the migration as part of the desired state, and initContainers or Helm hooks enforce ordering before the Deployment rolls out. This keeps the migration auditable and reproducible.

Answer

Add a 'kubectl apply' command to the end of the CI pipeline to execute migrations.

Answer

Hardcode the migration logic into the application source code to run on startup.

Answer

Create a manual trigger in the GitOps dashboard to execute the migration after the deployment starts.

Answer

Configure the GitOps agent to execute a shell script on the node before pulling the image.

Question 10

When implementing multi-cluster GitOps, which THREE components are critical for success? (Select three)

Accepted Answer

Secure communication channel (e.g., mTLS/VPN) between management and targets.. Option A is correct because multi-cluster GitOps requires a secure communication channel such as mTLS or a VPN between the management plane and target clusters, ensuring that configuration pushes, reconciliation traffic, and credentials are protected against interception or tampering. Option B is correct because a centralized management cluster (Hub) provides the single control point that hosts the GitOps operator (e.g., Argo CD or Flux) and from which all target clusters are registered, reconciled, and observed. Option D is correct because environment-specific configuration separation via Kustomize overlays (or equivalent Helm values) lets one base manifest be safely promoted across dev/staging/prod clusters without duplicating or hard-coding per-environment differences. Option C is not appropriate because secrets should be managed through dedicated secret stores or sealed-secrets mechanisms integrated with GitOps, not a shared database that becomes a single point of compromise and is not a standard GitOps component. Option E is not required because GitOps reconciliation is asynchronous and eventually consistent; uniform latency across clusters is neither achievable nor necessary for success.

Answer

A shared database for all clusters to store secrets.

Answer

Uniform network latency across all clusters.

Question 11

Which THREE factors should be considered when choosing a GitOps controller?

Accepted Answer

The controller's support for multi-cluster deployments.. Option B is correct because a GitOps controller's ability to manage multiple clusters (e.g., via Argo CD's cluster registration or Flux's multi-cluster support with Kustomization/HelmRelease resources) is a key architectural factor when you operate more than one Kubernetes cluster. Option D is correct because the controller must integrate with your existing CI/CD pipelines—typically by watching a Git repository that CI tools such as Jenkins, GitLab CI, or GitHub Actions update—so the build-and-deploy workflow remains coherent. Option E is correct because GitOps repositories often contain manifests referencing secrets, so built-in integration or compatibility with secret management solutions (e.g., Sealed Secrets, External Secrets Operator, SOPS, or Vault) is essential for secure, automated reconciliation. Option A is not a valid factor because UI color scheme is cosmetic and has no bearing on functionality, scalability, or operational fit. Option C is not a valid factor because using a proprietary language is not inherently disqualifying; what matters is whether the controller's configuration format and ecosystem fit your team, and many controllers use standard YAML or established templating rather than a proprietary DSL.

Answer

The color scheme of the controller's UI.

Answer

Whether it uses a proprietary language.

Question 12

A senior cloud architect is designing a multi-tenant platform using GitOps. They want to ensure that continuous drift detection and correction operate reliably without causing system instability. Which TWO practices help mitigate risks associated with automated continuous drift correction?

Accepted Answer

Configuring the GitOps controller to ignore specific dynamic fields updated by in-cluster controllers, such as 'spec.replicas' managed by a HorizontalPodAutoscaler (HPA).. Option C is correct because GitOps controllers such as Argo CD or Flux continuously reconcile live state to Git, and fields like 'spec.replicas' that are legitimately mutated by an in-cluster controller (an HPA) will otherwise be perpetually reverted, causing a fight between controllers and instability; configuring ignoreDifferences (Argo CD) or equivalent field exclusions prevents this. Option E is correct because running drift detection in a non-mutating mode first — Argo CD's diff view or sync with --dry-run, or alerting on OutOfSync status — surfaces unexpected drift to teams before self-healing applies destructive changes (e.g., deleting or recreating critical resources), which is the standard risk-mitigation pattern for automated correction. Option A is wrong because granting cluster-admin to all developers and allowing manual disabling of drift correction destroys the security model and auditability of GitOps rather than mitigating risk. Option B is wrong because removing Git versioning and comparing against an unversioned NFS share eliminates the single source of truth, rollback capability, and drift provenance that GitOps depends on. Option D is wrong because a 30-second reconciliation interval with a full node reboot per iteration is operationally catastrophic and would itself cause the instability the architect is trying to avoid.

Answer

Granting full cluster-admin permissions to all application developers so they can manually disable drift correction during deployments.

Answer

Disabling Git versioning so that drift detection compares live state against an unversioned NFS network share.

Answer

Setting the reconciliation loop interval to run once every 30 seconds while forcing a full cluster node reboot on every iteration.

Question 13

Which TWO aspects of GitOps help ensure 'Continuous Drift Detection'?

Accepted Answer

Comparing live state with the desired state in Git.. Option C is correct because Continuous Drift Detection fundamentally relies on continuously comparing the live state of the cluster against the desired state declared in Git, which is the single source of truth in GitOps; any divergence between the two constitutes drift. Option D is correct because this comparison must happen continuously, which is achieved through regular polling of the cluster or event-based monitoring (e.g., Kubernetes controllers, webhooks, or GitOps agents like Argo CD or Flux reconciling on an interval or on change events). Together, C and D describe the mechanism (compare live vs. desired) and the trigger (continuous polling/events) that make drift detection continuous. Option A is incorrect because daily manual audit reports are periodic and human-driven, not continuous or automated. Option B is incorrect because mandating SSH for developers is an access-control practice unrelated to drift detection. Option E is incorrect because storing cluster state in a database is not how GitOps detects drift; the desired state lives in Git, and drift is found by comparing it to the live cluster, not by querying a separate database.

Answer

Daily manual audit reports.

Answer

Forcing all developers to use SSH.

Answer

Using a database to store current cluster state.

Question 14

Which TWO of the following tools allow for GitOps policy enforcement?

Accepted Answer

OPA Gatekeeper. OPA Gatekeeper (A) is correct because it is a Kubernetes admission controller that enforces policies written in Rego, allowing GitOps pipelines to validate and reject non-compliant manifests before they are applied to the cluster. Kyverno (E) is also correct because it provides Kubernetes-native policy enforcement via validating, mutating, and generating admission rules, which integrates with GitOps workflows to ensure only policy-compliant resources are deployed. Helm (B) is a package manager for templating and deploying Kubernetes manifests, not a policy enforcement engine. ArgoCD (C) and Flux (D) are GitOps continuous delivery tools that sync cluster state with Git, but they do not themselves enforce policy; they rely on tools like Gatekeeper or Kyverno for that purpose.

Answer

Helm

Answer

ArgoCD

Answer

Flux

Question 15

Which TWO of the following are true about the 'Pull' model in GitOps? (Select two)

Accepted Answer

It improves security by removing the need for cluster credentials in CI.. Option A is correct because in the Pull model the GitOps agent (e.g., Argo CD or Flux) runs inside the cluster and pulls desired state from Git, so the CI system never needs kubeconfig or cluster credentials to push changes, reducing the attack surface. Option B is correct because the in-cluster agent continuously watches Git and the live cluster, automatically reconciling drift so the cluster converges back to the declared state without external triggering. Option C is wrong because the Pull model is tool-agnostic and works with plain YAML, Kustomize, Helm, Jsonnet, and other manifest sources. Option D is wrong because the agent initiates outbound connections to Git (HTTPS/SSH), so no inbound firewall port needs to be opened on the cluster. Option E is wrong because reconciliation is performed by the always-running in-cluster agent, not by a CI pipeline that must stay active 24/7.

Answer

It is only supported for Helm charts.

Answer

It requires opening an inbound port on the cluster firewall.

Answer

It requires the CI pipeline to be active 24/7.