CGOA Practice Test 11 — 15 Questions

Question 1

Your organization wants to implement DevSecOps by integrating security scanning into a GitOps pipeline. Where should the vulnerability scan happen to prevent insecure configurations from ever reaching the cluster?

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

Accepted Answer

During the CI phase, scanning the Kubernetes manifests for security misconfigurations before merging.. To prevent insecure configurations from reaching the cluster, scanning must occur early in the CI phase, ideally on the Kubernetes manifests before they are merged into the Git repository. This shift-left approach catches misconfigurations before deployment, aligning with DevSecOps principles.

Answer

Only when an auditor requests a security report.

Answer

By running an automated script to delete pods that fail a security check.

Answer

As a post-deployment check using a Kubernetes admission controller.

Question 2

If you want to view the history of changes made to your cluster configuration, where should you look in a GitOps model?

Accepted Answer

The Git repository commit history. In a GitOps model, Git is the single source of truth for the desired state of the cluster, so the commit history of the Git repository is the authoritative audit trail of every configuration change. Each commit records who changed what and when, and Argo CD or Flux ties deployed revisions back to specific commits. This is the core GitOps principle: the cluster's change history lives in version control, not in the cluster itself.

Answer

The cluster event logs

Answer

The developer's local workstation

Answer

The cloud provider billing dashboard

Question 3

What happens when a resource's 'SyncPolicy' is set to 'Manual'?

Accepted Answer

The operator will report 'OutOfSync' until a human triggers the sync. When SyncPolicy is set to Manual, the GitOps operator still watches the repository and computes the diff between desired and live state, but it does not apply changes automatically. As soon as a difference is detected, the application is marked OutOfSync, and it remains in that state until a human explicitly triggers a sync (e.g., via the UI, CLI, or API). This gives operators control over when changes hit the cluster, which is useful for production environments requiring approval gates.

Answer

The operator will delete the resource

Answer

The operator will stop watching the repository

Answer

The operator will automatically sync as soon as a change is detected

Question 4

When configuring a GitOps pipeline, what should be done to manage sensitive data like API keys?

Accepted Answer

Use a tool like Sealed Secrets to encrypt them before committing to Git.. Sealed Secrets is a Kubernetes controller and tool that allows you to encrypt secrets into a 'SealedSecret' resource that is safe to store in a Git repository. The SealedSecret can only be decrypted by the controller running in the target cluster, ensuring that sensitive data is not exposed in plain text. This aligns with GitOps principles by keeping all configuration, including secrets, version-controlled and declarative.

Answer

Store them in base64 encoded format in plain Git.

Answer

Leave them out of Git and manually inject them via kubectl.

Answer

Upload them to the cluster via the cloud provider's console.

Question 5

You are performing a Canary deployment using Argo Rollouts. You notice that the analysis template is failing even though the metrics are within range. What is the most common cause of this in a GitOps workflow?

Accepted Answer

The Prometheus metric query does not match the 'args' passed from the Rollout object.. In Argo Rollouts canary deployments, the AnalysisTemplate defines metrics queries (e.g., Prometheus PromQL) and can accept arguments passed from the Rollout's analysis step. If the query references template variables (like {{args.service-name}}) that don't match the args defined in the Rollout's analysis step, the query fails to render or returns invalid results, causing the analysis to fail even when actual metrics are healthy. This mismatch is the most common GitOps misconfiguration.

Answer

The analysis template is missing the 'rollback' flag.

Answer

The Rollout image version is not updated in the Git repository.

Answer

The ReplicaSet is failing to scale to the desired state.

Question 6

When mapping a traditional CI/CD pipeline to GitOps, what is the primary role of the CD tool?

Accepted Answer

Reconciling the running state of the cluster with the declarative state defined in Git.. In GitOps, the CD tool (e.g., Argo CD or Flux) acts as a reconciliation controller that continuously compares the desired state declared in Git against the live cluster state and applies any drift corrections. It does not build or push artifacts — that is the CI system's job. The CD tool's core function is to pull the declarative manifests from Git and ensure the cluster matches them.

Answer

Pushing binary artifacts to a server via SSH.

Answer

Pushing images to a container registry after a build.

Answer

Generating test reports for the QA team.

Question 7

A team is transitioning to GitOps. Which action best aligns with the principle of Declarative Desired State?

Accepted Answer

Storing YAML manifests in Git representing the target environment state. Declarative desired state in GitOps means the target environment state is expressed as declarative manifests (for example, Kubernetes YAML) stored in Git as the single source of truth. A controller then reconciles the live environment to match that declared state, which is exactly what storing YAML manifests in Git represents.

Answer

Running a pipeline to execute terraform apply on demand

Answer

Writing a bash script to update image tags on all clusters

Answer

Using kubectl edit to modify running pod replicas

Question 8

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.

Question 9

Your team wants to implement GitOps. Which of the following is a critical prerequisite for 'Drift Detection' to be effective?

Accepted Answer

The operator must have read access to the Git repository and the cluster's current live state.. Drift detection in GitOps works by continuously comparing the desired state stored in Git with the actual live state of the cluster. To perform this comparison, the GitOps operator (e.g., Argo CD, Flux) must be able to read both the Git repository (to fetch the desired manifests) and the cluster's live resources (to observe the current state). Without read access to both, the operator cannot detect any divergence, making drift detection impossible.

Answer

The cluster must have an external load balancer exposed to the internet.

Answer

Developers must manually commit to Git every time a pod restarts.

Answer

The Git repository must contain the running container images themselves.

Question 10

A team is transitioning from traditional imperative scripts to declarative Configuration as Code. Which approach best satisfies the GitOps principle of using a desired state definition?

Accepted Answer

Storing Kubernetes YAML manifests in a Git repository and using an operator to synchronize them.. Storing Kubernetes YAML manifests in a Git repository and using an operator to synchronize them is the declarative GitOps approach. The YAML files define the desired state, and the operator continuously reconciles the cluster to match that state. This satisfies the principle of using a desired state definition because the state is versioned, immutable, and declarative.

Answer

Using bash scripts triggered by a Jenkins build job to update environment variables.

Answer

Directly editing deployments via the 'kubectl edit' command.

Answer

Using an Ansible playbook to perform one-off configuration changes on existing servers.

Question 11

A DevOps team is storing its Kubernetes manifests in a Git repository. To adhere strictly to the principle of versioned and immutable desired state in Git, how should the team manage changes to an existing deployment's container image tag?

Accepted Answer

Commit a change updating the image tag in the manifest file within the Git repository and merge it via a pull request.. In GitOps, Git is the single source of truth for desired state, so any change to a deployment—including the container image tag—must be made by committing to the manifest in Git and merging via a pull request. The GitOps controller then reconciles the cluster to match. Direct cluster mutations bypass the audit trail and are reverted by reconciliation.

Answer

Exec into the running pod using 'kubectl exec' and update the container image binary directly.

Answer

Run 'kubectl set image deployment/my-app my-app=image:v2' against the live cluster without updating Git.

Answer

Delete the deployment using 'kubectl delete' and manually re-apply a temporary local manifest file.

Question 12

When using Kyverno, which THREE of the following can be used to validate Kubernetes resources?

Accepted Answer

Conditional logic (if/then). Kyverno validates Kubernetes resources through declarative policy rules, and option C (conditional logic (if/then)) is correct because Kyverno supports `if`/`else` conditional blocks within rules to evaluate resource attributes and conditionally apply validation behavior. Option D (pattern matching) is correct because Kyverno's `pattern` and `anyPattern` match blocks perform structural, wildcard-based matching against resource manifests to enforce required fields and values. Option E (JMESPath expressions) is correct because Kyverno uses JMESPath in `preconditions`, `deny` conditions, and variable substitution to query and evaluate fields within the admission request object. Options A (SQL queries) and B (Bash scripting) are not part of Kyverno's policy language; Kyverno policies are YAML-based and do not execute SQL or shell scripts for validation.

Answer

SQL queries

Answer

Bash scripting

Question 13

Which TWO of the following are common challenges when implementing GitOps in an organization?

Accepted Answer

Addressing configuration drift caused by manual changes to the cluster.. Option A is correct because GitOps relies on Git as the single source of truth, so any manual kubectl edits or out-of-band changes create configuration drift that the reconciliation loop must detect and revert, which is a well-known operational challenge. Option B is correct because storing secrets in plaintext in Git repositories is insecure; teams must adopt solutions such as Sealed Secrets, SOPS, External Secrets Operator, or HashiCorp Vault to keep credentials encrypted and out of the version history. Option C is incorrect because GitOps does not mandate open-source-only tooling; commercial and proprietary platforms can implement the same declarative pull-based model. Option D is incorrect because Git server pull-request throughput is not a typical GitOps adoption challenge; the bottleneck is usually reconciliation and drift management, not PR processing speed. Option E is incorrect because GitOps is inherently tied to containerized, Kubernetes-style declarative workloads, so a lack of containerization support would be a prerequisite issue rather than a common implementation challenge.

Answer

The requirement to use only open-source software.

Answer

The speed at which Git servers process pull requests.

Answer

The lack of support for containerization in the organization.

Question 14

Which of the following is a primary benefit of using a GitOps pull-based model over a push-based CI/CD model?

Accepted Answer

Removal of the need for external access to cluster credentials.. In a pull-based GitOps model, an in-cluster agent (e.g., Argo CD, Flux) pulls desired state from Git, so external CI systems never need cluster credentials. This removes the need to store or expose kubeconfig/API credentials outside the cluster, significantly reducing the attack surface.

Answer

Automatic code compilation within the cluster.

Answer

Support for imperative commands.

Answer

Faster deployment velocity.

Question 15

What is the primary benefit of a 'pull' deployment model compared to a 'push' model in GitOps?

Accepted Answer

Reduced need for inbound firewall access to the cluster. In a pull-based GitOps model, an in-cluster agent (e.g., Argo CD or Flux) continuously reconciles the desired state from Git with the live cluster. Because the agent initiates outbound connections to Git and the cluster does not need to accept inbound connections from an external CI/CD system, the need for inbound firewall access to the cluster is significantly reduced — a major security and operational benefit.

Answer

Support for non-Kubernetes platforms

Answer

Elimination of Kubernetes manifests

Answer

Faster application builds