CGOA Multiple Select — 60 Questions

Question 1

Which TWO of the following are considered 'Anti-Patterns' in a GitOps workflow? (Choose two)

Accepted Answer

Storing sensitive secrets as plain text in the Git repository.. Option A is correct because committing secrets as plain text in Git exposes credentials to anyone with repository read access and permanently embeds them in Git history, violating GitOps' declarative, auditable, and secure source-of-truth model; secrets should instead be managed with tools like Sealed Secrets, SOPS, or an external secrets manager. Option C is correct because making manual changes directly to the production cluster creates configuration drift from the Git-declared desired state, breaking the core GitOps principle that Git is the single source of truth and that all changes flow through version control and automated reconciliation. Option B is not an anti-pattern; using branches (or directories) per environment is a legitimate, widely used GitOps repository strategy for separating prod and dev configurations. Option D is not an anti-pattern; automating deployment with a GitOps operator such as Argo CD or Flux is the intended practice, as it continuously reconciles cluster state with Git. Option E is not an anti-pattern; storing application manifests in a central repository is a standard GitOps pattern that provides a single, versioned source of truth for deployments.

Answer

Using a Git branch to represent a specific environment (e.g., prod vs dev).

Answer

Automating the deployment process using a GitOps operator.

Answer

Storing application manifests in a central repository.

Question 2

Which TWO of the following are NOT recommended in a GitOps workflow?

Accepted Answer

Manual changes via kubectl. Option B (Manual changes via kubectl) is NOT recommended in a GitOps workflow because GitOps requires the Git repository to be the single source of truth, and any out-of-band change made directly with kubectl creates configuration drift that the reconciliation controller will detect and revert, defeating the declarative model. Option C (Storing plain-text secrets in the repository) is NOT recommended because committing unencrypted credentials to Git exposes sensitive data to anyone with repository access and to the permanent Git history, violating security best practices; secrets should instead be managed with tools like Sealed Secrets, SOPS, or an external vault. By contrast, option A (Automated reconciliation of state) is a core GitOps principle, typically implemented by controllers such as Argo CD or Flux continuously comparing live cluster state to the desired state in Git. Option D (Using Git as a source of truth) is the foundational GitOps tenet, providing versioning, auditability, and rollback. Option E (Using pull requests for code changes) is recommended because it enables peer review, CI validation, and an auditable approval trail before changes are merged and deployed.

Answer

Automated reconciliation of state

Answer

Using Git as a source of truth

Answer

Using pull requests for code changes

Question 3

A team is reviewing their deployment practices against OpenGitOps standards. Which THREE conditions are required to satisfy the 'Declarative Desired State' and 'Versioned and Immutable State' principles?

Accepted Answer

The target system's desired state is expressed in a software-interpretable, declarative format like YAML or JSON.. Option A is correct because the OpenGitOps 'Declarative Desired State' principle requires that the intended state of the system be expressed in a declarative, software-interpretable format such as YAML or JSON, so tooling can read and reconcile it automatically. Option B is correct because 'Versioned and Immutable State' requires the desired state to live in a version-controlled repository whose history is append-only, meaning changes are added as new revisions rather than overwriting or deleting prior ones. Option C is correct because each revision must be uniquely identifiable—typically by a Git commit SHA—and fully reproducible, so any past state can be reconstructed and audited. Option D does not belong because allowing live cluster state to override the repository breaks the single source of truth and the immutability of the declared desired state. Option E does not belong because manual shell scripts executed directly on production control plane nodes are imperative, unversioned, and non-reproducible, contradicting both principles.

Answer

Live cluster state is permitted to override repository configurations during peak traffic periods.

Answer

System changes are made by executing manual shell scripts directly on production control plane nodes.

Question 4

When evaluating ArgoCD vs Flux, which TWO of the following are distinct advantages of using Flux?

Accepted Answer

Modular, controller-based architecture. Option D is correct because Flux is built as a set of independent Kubernetes controllers (source-controller, kustomize-controller, helm-controller, notification-controller), each with a single responsibility, which allows operators to install only the components they need and to scale or upgrade them independently — a modular design that contrasts with ArgoCD's more monolithic application-server model. Option E is correct because Flux natively reconciles multiple Git repositories through multiple GitRepository sources, each watched by its own Kustomization or HelmRelease, so a single Flux installation can continuously reconcile many repos without extra tooling. The unmarked options do not belong: A and B describe ArgoCD's strengths, since ArgoCD ships a built-in web UI with graphical RBAC management, whereas Flux is CLI/GitOps-centric and configures RBAC through Kubernetes manifests; C is also an ArgoCD feature, as ArgoCD provides visual sync waves and health status in its dashboard, while Flux expresses ordering via dependsOn and health checks rather than a graphical sync-wave view.

Answer

Built-in web-based graphical dashboard

Answer

RBAC managed via UI

Answer

Visual sync waves

Question 5

An organization is implementing GitOps across its infrastructure using Kubernetes and Flux. Which TWO statements accurately describe core characteristics of the 'Automated Pull-Based Reconciliation' principle?

Accepted Answer

Reconciliation automatically corrects drift when actual live cluster state deviates from desired Git state.. Option A is correct because automated pull-based reconciliation continuously compares the desired state declared in Git with the actual live state in the cluster and automatically remediates any drift, restoring resources to the declared configuration. Option C is correct because in the pull model an in-cluster agent such as Flux's source-controller/kustomize-controller periodically fetches (polls) the Git repository and applies changes, so no inbound connection to the cluster is needed. Option B is wrong because pull-based GitOps never has Git initiate inbound SSH connections to worker nodes; the cluster agent pulls from Git instead. Option D is wrong because the whole point of pull-based GitOps is that external CI systems do not need cluster administrative credentials, which stay inside the cluster. Option E is wrong because reconciliation is automated and continuous, not gated by manual human approval for each resource sync.

Answer

The Git repository initiates an inbound SSH connection to cluster worker nodes to push manifest updates.

Answer

Cluster administrative credentials must be stored inside external CI system secret stores.

Answer

Reconciliation requires direct human approval at the terminal for every individual resource sync.

Question 6

Which TWO tools are commonly associated with the 'GitOps' ecosystem?

Accepted Answer

Argo CD.. Argo CD (D) is a declarative, GitOps continuous-delivery controller for Kubernetes that continuously reconciles the live cluster state against manifests stored in a Git repository, making it a flagship GitOps tool. Flux (E) is likewise a CNCF GitOps toolkit that watches Git repositories and applies/reconciles Kubernetes manifests, so it is equally central to the GitOps ecosystem. Docker Desktop (A) is a local container build/run environment, Nginx (B) is a web server/reverse proxy, and Prometheus (C) is a metrics monitoring and alerting system; none of these implement Git-based declarative reconciliation, so they are not GitOps tools.

Answer

Docker Desktop.

Answer

Nginx.

Answer

Prometheus.

Question 7

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 8

Which THREE of the following are common GitOps tools used in the CNCF ecosystem?

Accepted Answer

Crossplane.. Crossplane (A) is a CNCF project that extends Kubernetes with custom resources to provision and manage cloud infrastructure declaratively, making it a common GitOps tool for infrastructure-as-code workflows. Flux (B) is a CNCF graduated project that continuously reconciles Kubernetes cluster state with Git repositories, embodying the core GitOps pull-based model. Argo CD (D) is also a CNCF graduated project that performs declarative, Git-based continuous delivery for Kubernetes by syncing cluster resources to a desired state stored in Git. Apache HTTP Server (C) is a general-purpose web server and MySQL (E) is a relational database; neither is a GitOps reconciliation or continuous delivery tool, so they do not belong in this list.

Answer

Apache HTTP Server.

Answer

MySQL.

Question 9

Which TWO of the following are true about ArgoCD ApplicationSets?

Accepted Answer

They support multi-cluster generators. Option A is correct because ApplicationSets provide generators such as the Cluster generator, which enumerates clusters registered in ArgoCD (via cluster Secrets) and produces one Application per cluster, enabling true multi-cluster deployments. Option D is correct because an ApplicationSet controller renders a template against generator output to automatically create, update, and delete ArgoCD Application resources, removing the need to hand-write each Application manifest. Option B is wrong since ApplicationSets are explicitly designed to target many clusters, not just the local one. Option C is wrong because ApplicationSets only generate Application CRs; image building is handled by CI tools like Jenkins, GitLab CI, or Tekton, not ArgoCD. Option E is wrong because ApplicationSets still rely on Git (or another generator source) as the desired-state source of truth and do not replace it.

Answer

They are only for local clusters

Answer

They handle container image builds

Answer

They replace the need for Git

Question 10

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 11

Which TWO of the following are common GitOps terminology used to describe the state of an application?

Accepted Answer

Desired State. In GitOps, the Desired State (B) is the declarative configuration stored in Git that defines how the application and its infrastructure should look, serving as the single source of truth that the GitOps operator continuously reconciles toward. The Live State (C), also called the observed or actual state, is the real-time condition of the running application and cluster as reported by the GitOps agent (e.g., Argo CD or Flux), which is compared against the desired state to detect drift. These two terms form the core reconciliation loop of GitOps: the controller drives the live state to match the desired state. The other options are not GitOps terminology: Temporary State (A), Future State (D), and Legacy State (E) are not standard terms used to describe application state in GitOps workflows.

Answer

Temporary State

Answer

Future State

Answer

Legacy State

Question 12

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 13

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 14

Which TWO of the following best describe the benefits of adopting GitOps?

Accepted Answer

Better auditability through a full history of changes in Git.. Option A is correct because GitOps stores all desired-state manifests in Git, so every change is a versioned commit with author, timestamp, and diff, giving a complete, immutable audit trail of who changed what and when. Option B is correct because GitOps controllers such as Argo CD or Flux continuously reconcile the live cluster against the declarative state in Git, detecting and correcting drift so the cluster converges on the committed desired state. Option C is wrong because GitOps does not bypass testing; CI pipelines still run tests and validation before changes are merged and synced. Option D is wrong because GitOps reduces manual operator intervention through automated reconciliation rather than increasing dependence on it. Option E is wrong because GitOps still relies on container images pulled from a registry; Git holds the manifests, not the image layers.

Answer

Higher speed because testing is bypassed.

Answer

Increased dependence on manual operator intervention.

Answer

The ability to run without any container registry.

Question 15

Which TWO of the following are benefits of using Git as the 'Source of Truth'?

Accepted Answer

Clear audit trail of who changed what and when. Option A is correct because Git records every commit with author identity, timestamp, and a cryptographic hash of the exact changes, giving an immutable, reviewable history of who changed what and when — the essence of an audit trail for a source of truth. Option B is correct because Git's versioned history lets you undo a bad change deterministically with commands like git revert (which creates a new commit that inverts a prior one) or git reset, enabling reliable rollback to a known-good state. Option C is wrong because Git is a version-control system for code and configuration, not a cloud IAM or account-lifecycle tool; it cannot detect or delete unused cloud accounts. Option D is wrong because Git reduces reliance on manual terminal access by providing a structured, reviewable workflow (commits, branches, pull requests) rather than encouraging ad-hoc manual changes. Option E is wrong because Git has no bearing on application CPU performance; it manages source history, not runtime compute resources.

Answer

Automatic removal of unused cloud accounts

Answer

Increased reliance on manual terminal access

Answer

Faster CPU performance for applications

Question 16

Which TWO of the following are primary benefits of storing immutable state in Git?

Accepted Answer

Reduction in manual cluster configuration errors. Option A is correct because storing immutable state in Git (the GitOps model) makes the desired cluster configuration declarative and version-controlled, so changes are reviewed and applied consistently, which reduces manual, error-prone cluster configuration. Option D is correct because every change to the desired state is a Git commit, giving a complete, auditable history of who changed what and when, enabling rollback and traceability of all environment changes. Option B is not a primary benefit of immutable Git state, since hotfix speed depends on the CI/CD pipeline and deployment process, not on storing state in Git. Option C is incorrect because Git does not automatically convert Docker images into YAML manifests; that requires separate tooling. Option E is incorrect because Git stores configuration, not server storage capacity, so it does not increase server-side storage.

Answer

Faster deployment of hotfixes directly to production

Answer

Automated conversion of Docker images to YAML

Answer

Increased server-side storage capacity

Question 17

Which TWO of the following are characteristics of a 'GitOps Operator'?

Accepted Answer

It runs inside the Kubernetes cluster. Option C is correct because a GitOps Operator is deployed as a controller inside the Kubernetes cluster, where it watches custom resources and continuously manages the desired state of the environment. Option E is correct because the core function of a GitOps Operator is to observe the live cluster state, compare it against the desired state declared in Git, and act to reconcile any drift automatically. Options A, B, and D are incorrect: a GitOps Operator is not merely an external monitoring tool, it does not generate application source code, and it does not require manual triggers for every update since reconciliation is continuous and automated.

Answer

It is a purely external monitoring tool

Answer

It generates application source code

Answer

It requires manual triggers for every update

Question 18

Which TWO are examples of 'Drift' in a GitOps environment?

Accepted Answer

A manual update to a Deployment image via kubectl.. In GitOps, drift is any divergence between the desired state stored in Git and the actual state running in the cluster. Option B is correct because running kubectl to change a Deployment's image modifies the live cluster state outside of Git, so the actual state no longer matches the declared manifest, which is classic configuration drift. Option E is correct because editing a Service type directly in the cluster (e.g., changing ClusterIP to NodePort) also bypasses Git and creates a mismatch between the declared and observed state. Option A is not drift because a CPU spike is a transient runtime metric, not a configuration divergence from Git. Option C is not drift because a container crash is an application/runtime failure, not a change to the declared desired state. Option D is not drift because a new Git commit updates the desired state itself and is the normal GitOps change mechanism, not a divergence from it.

Answer

A temporary spike in CPU usage.

Answer

A container crashing due to a code bug.

Answer

A new Git commit.

Question 19

Which TWO of the following are features of progressive delivery in GitOps? (Select two)

Accepted Answer

Gradual traffic shifting between application versions.. Option A is correct because progressive delivery in GitOps is fundamentally about gradually shifting traffic between application versions—using techniques like canary releases or blue-green deployments—so that a new version receives only a small percentage of traffic initially and that share increases as confidence grows. Option C is correct because progressive delivery tightly couples traffic shifting with automated analysis of custom metrics (e.g., error rate, latency, or business KPIs); if those metrics breach defined thresholds, the rollout is automatically rolled back, which is a core GitOps progressive delivery capability. Option B is not a feature of progressive delivery—manually logging into pods is an ad-hoc, non-automated troubleshooting step that contradicts the automated, declarative nature of GitOps. Option D is incorrect because immediate deployment of all changes to the entire cluster is a big-bang release, the opposite of progressive delivery's incremental rollout. Option E is incorrect because removing health checks would eliminate the very signals progressive delivery relies on to validate a rollout and trigger automated rollback.

Answer

Manually logging into pods to check health.

Answer

Immediate deployment of all changes to the entire cluster.

Answer

Removing all health checks from the application.

Question 20

Which TWO of the following are valid strategies for promoting an application from staging to production in GitOps? (Select two)

Accepted Answer

Merging a pull request from a staging branch to a production branch.. Option C is correct because in GitOps the Git repository is the single source of truth, so promoting an application is done by merging a pull request from a staging branch into a production branch, which changes the desired state that the GitOps operator (e.g., Argo CD or Flux) then reconciles into the production cluster. Option E is correct because GitOps commonly uses a directory-per-environment layout (e.g., kustomize overlays or Helm values files), so updating the environment-specific values file in the production directory commits the new desired production configuration, which the GitOps controller detects and applies. Option A is not a valid promotion strategy because deleting and recreating the application discards state and is not a declarative Git-driven promotion. Option B is not valid because 'kubectl rollout undo' is an imperative manual rollback that bypasses Git and would be reverted by the GitOps reconciler. Option D is not valid because pushing directly to the cluster bypasses the CI/CD pipeline and Git, violating the core GitOps principle that all changes flow through Git.

Answer

Deleting the application and recreating it.

Answer

Running a 'kubectl rollout undo' command manually.

Answer

Bypassing the CI/CD pipeline by pushing directly to the cluster.