CGOA Gitops Principles Practice Test 4 — 15 Questions

Question 1

Which THREE actions occur when a GitOps controller detects drift?

Accepted Answer

The controller generates an alert/notification.. When a GitOps controller (e.g., Argo CD or Flux) detects that live cluster state diverges from the desired state stored in Git, it flags the affected resource as 'OutOfSync' (option C), which is the standard status used by tools like Argo CD to indicate drift between the Git manifest and the running object. It also generates an alert or notification (option A) so operators are informed of the drift, typically via webhooks, Slack, or email integrations. Finally, the controller reconciles by applying the desired state from Git to the cluster (option D), overwriting the manual change to restore the declared configuration. Option B is wrong because no GitOps controller deletes the entire cluster on drift; that is not a defined reconciliation behavior. Option E is wrong because GitOps is one-directional from Git to the cluster — the controller does not push manual cluster changes back into Git, as Git remains the single source of truth.

Answer

The controller automatically deletes the cluster.

Answer

The controller pushes the manual changes back to Git.

Question 2

Which TWO characteristics help ensure a GitOps repository is auditable?

Accepted Answer

Cryptographically signed commits to verify authorship.. Option C is correct because cryptographically signed commits (e.g., using GPG or SSH signatures verified via git commit -S and git verify-commit) provide non-repudiable proof of who authored a change, which is essential for auditability in a GitOps repository. Option D is correct because detailed commit logs capturing author identity and timestamp (as recorded in the commit object's author/committer fields and shown by git log) create a traceable history of every change, satisfying audit requirements. Option A is incorrect because restricting pushes to a single admin user does not by itself provide an audit trail and actually reduces traceability of who made changes. Option B is incorrect because using private email addresses obscures author identity rather than making the repository more auditable. Option E is incorrect because storing files as binary blobs prevents meaningful diffs and review of changes, undermining auditability.

Answer

Only allowing the admin user to push code.

Answer

Use of private email addresses in commit logs.

Answer

Storing all files as binary blobs.

Question 3

Which THREE of these are valid methods for handling configuration differences across environments (e.g., Dev vs Prod)?

Accepted Answer

Using separate directories for each environment's manifests.. Option A is correct because maintaining separate directories per environment (e.g., overlays/dev, overlays/prod or manifests/dev, manifests/prod) is a standard GitOps-friendly pattern that keeps environment-specific manifests isolated and version-controlled. Option B is correct because Helm values files (e.g., values-dev.yaml, values-prod.yaml) let you override chart parameters per environment via helm install -f values-prod.yaml, cleanly separating configuration from templated manifests. Option E is correct because Kustomize overlays (kustomization.yaml with bases and overlays) are purpose-built for patching a common base with environment-specific changes such as replicas, image tags, or resource limits. Option C is not a valid method because manually SSHing into nodes to run sed is imperative, unversioned, and unreproducible, causing configuration drift. Option D is not valid because hardcoding every environment into one massive file creates tight coupling, raises error risk, and defeats the separation-of-concerns that these declarative tools provide.

Answer

Manually SSHing into nodes to run sed.

Answer

Hardcoding every environment in one massive file.

Question 4

Which TWO benefits does GitOps provide for team collaboration?

Accepted Answer

Providing a transparent, versioned history of infrastructure changes.. Option C is correct because GitOps stores the desired state of infrastructure as declarative configuration in a Git repository, so every change is committed with an author, timestamp, and diff, giving the whole team a transparent, versioned audit trail that can be inspected, reverted, or compared across branches and tags. Option E is correct because GitOps workflows route all changes through Git, so modifications are proposed as branches and merged via Merge Requests (or Pull Requests), enabling peer review, comments, approvals, and CI checks before anything reaches the cluster. The unmarked options do not belong: A is wrong because GitOps still requires communication for design and incident response, B is wrong because GitOps is tool-agnostic and does not mandate any IDE, and D is wrong because GitOps actually increases oversight by requiring reviewed, approved merges rather than unmonitored deployments.

Answer

Removing the need for communication.

Answer

Forcing everyone to use the same IDE.

Answer

Allowing developers to deploy without oversight.

Question 5

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 6

Which THREE mechanisms can be used to notify a GitOps controller of a change in Git?

Accepted Answer

Git repository webhooks.. Option B (Git repository webhooks) is correct because a Git host such as GitHub, GitLab, or Bitbucket can send an HTTP POST webhook to the GitOps controller's receiver endpoint whenever a push or merge occurs, triggering immediate reconciliation. Option C (Manual refresh request via CLI/UI) is correct because tools like Argo CD and Flux expose commands such as `argocd app get --refresh` or a UI refresh button that force the controller to re-check Git on demand. Option D (Periodic polling of the Git repository) is correct because GitOps controllers run a reconciliation loop that polls the Git repository at a configured interval (e.g., Argo CD's default 3 minutes or Flux's `--poll-interval`) to detect new commits. Option A is not a notification mechanism to the controller; an SSH push only updates the remote repository and does not itself inform the GitOps controller. Option E is incorrect because a container crash is an unrelated runtime failure and does not signal a Git change to the controller.

Answer

SSH-based push from the local machine.

Answer

Waiting for a container crash.

Question 7

Which TWO are common strategies for GitOps repo structure?

Accepted Answer

Directory-per-environment.. Option B (Directory-per-environment) is correct because a common GitOps strategy is to organize a repository with separate directories for each environment (e.g., dev, staging, prod), allowing environment-specific manifests and overlays to be managed independently while sharing a common base. Option E (App-of-Apps pattern) is correct because in Argo CD-based GitOps, the App-of-Apps pattern uses a parent Application that points to a directory of child Application manifests, enabling hierarchical, declarative management of many applications from a single repo structure. Option A is not a standard GitOps repo-structuring strategy; while one repo per microservice can occur, GitOps commonly favors monorepos or environment-based layouts, and this is not one of the two recognized patterns here. Option C is incorrect because branches are routinely used in GitOps workflows (e.g., feature branches, environment branches), so 'never using branches' is not a valid strategy. Option D is incorrect because a single flat directory does not scale, provides no environment separation, and is not a recognized GitOps structuring strategy.

Answer

Creating one repository per single microservice.

Answer

Never using branches.

Answer

Storing all files in a single flat directory.

Question 8

Which THREE features of Kubernetes are commonly used to support GitOps?

Accepted Answer

The Kubernetes API for resource management.. Option A is correct because GitOps tools such as Argo CD and Flux reconcile the desired state stored in Git by continuously reading and writing resources through the Kubernetes API, which is the declarative control plane interface for creating, updating, and watching objects. Option C is correct because namespaces provide logical isolation and scoping for configuration, allowing GitOps-managed manifests and their associated RBAC, quotas, and policies to be separated per team, environment, or application. Option D is correct because RBAC restricts which users and service accounts can apply or modify resources, which is essential for GitOps controllers to have least-privilege permissions to sync Git-declared state without granting broad cluster-admin access. Option B is not a GitOps-supporting feature in this context because node labels are used by the scheduler for pod placement and do not implement declarative Git-to-cluster reconciliation. Option E is not relevant because internal clock synchronization supports time consistency for logs, certificates, and scheduling, but it is not a Kubernetes feature used to enable GitOps workflows.

Answer

Node labels for scheduling.

Answer

The cluster's internal clock synchronization.

Question 9

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 10

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 11

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 12

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 13

Why must the desired state be 'versioned' in Git in a GitOps architecture?

Accepted Answer

To enable reliable rollbacks and environment reproducibility.. Versioning the desired state in Git provides an immutable, auditable history of every change, enabling reliable rollbacks to any prior commit and reproducible environments by checking out a specific tag or SHA. This is the foundation of GitOps's declarative, auditable model. Versioning is about traceability and reproducibility, not about cluster-to-Git writes or resource optimization.

Answer

To allow the cluster to write data back to the Git repository.

Answer

To automatically optimize cluster resource utilization.

Answer

To ensure developers can commit code directly to production.

Question 14

You are using Argo CD. A developer manually scales a Deployment replica count using 'kubectl scale'. What happens next in a standard GitOps implementation?

Accepted Answer

The controller detects the drift and overwrites the manual change to match Git.. Argo CD continuously monitors the live cluster state against the desired state defined in Git. When a manual change like `kubectl scale` alters the replica count, Argo CD detects this as a drift from the Git-declared configuration. By default, Argo CD's reconciliation loop will automatically sync the application, overwriting the manual change to restore the replica count specified in Git. This enforces the GitOps principle that Git is the single source of truth.

Answer

Argo CD sends an alert but does not revert the change.

Answer

The controller updates Git to reflect the new replica count.

Answer

The change persists until the next Git commit.

Question 15

When defining a declarative desired state in Kubernetes, which attribute is essential to satisfy the 'declarative' principle?

Accepted Answer

A YAML manifest describing the final resource configuration.. The declarative principle in Kubernetes means you describe the desired end state of resources rather than the imperative steps to reach it. A YAML manifest (or JSON) expresses that final configuration, and the controller/API server reconciles actual state toward it. This is why 'kubectl apply -f manifest.yaml' is idempotent and repeatable, unlike imperative commands.

Answer

A shell script that executes 'kubectl apply'.

Answer

A webhook that triggers an update process.

Answer

A manual 'kubectl edit' command.