Troubleshooting practice questions

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

Trap 1: Manually logging into pods to check health.

Progressive delivery automates health evaluation through metrics, probes and analysis gates; manual pod logins cannot scale or gate a rollout and are not a GitOps feature. Manual inspection belongs to ad-hoc troubleshooting, not controlled canary or blue-green progression.

Trap 2: Immediate deployment of all changes to the entire cluster.

Progressive delivery exposes changes to a subset of users or traffic first, then widens gradually based on observed health. Pushing every change to the whole cluster at once is the opposite mechanism, leaving no staged verification or rollback window.

Trap 3: Removing all health checks from the application.

Progressive delivery depends on health checks and automated analysis to decide whether to advance or roll back a release. Stripping them removes the feedback signal entirely, so this contradicts the practice rather than describing it.

A
Gradual traffic shifting between application versions.
Gradual traffic shifting between application versions satisfies the incremental exposure constraint of progressive delivery. Unlike blue-green deployment, which flips all traffic at once, this mechanism routes a controlled percentage of requests to the new version, enabling canary analysis and rapid rollback before full rollout.
B
Manually logging into pods to check health.
Why it fails: Progressive delivery automates health evaluation through metrics, probes and analysis gates; manual pod logins cannot scale or gate a rollout and are not a GitOps feature. Manual inspection belongs to ad-hoc troubleshooting, not controlled canary or blue-green progression.
C
Automated rollback based on custom metrics.
Automated rollback driven by custom metrics is a progressive delivery feature because it closes the feedback loop: analysis templates in Argo Rollouts query Prometheus or Datadog, and a failed metric threshold triggers automatic rollback to the last stable ReplicaSet. This satisfies the stem's requirement for metric-gated, automated release control rather than manual intervention.
D
Immediate deployment of all changes to the entire cluster.
Why it fails: Progressive delivery exposes changes to a subset of users or traffic first, then widens gradually based on observed health. Pushing every change to the whole cluster at once is the opposite mechanism, leaving no staged verification or rollback window.
E
Removing all health checks from the application.
Why it fails: Progressive delivery depends on health checks and automated analysis to decide whether to advance or roll back a release. Stripping them removes the feedback signal entirely, so this contradicts the practice rather than describing it.

Question 2easymultiple choice

What is the primary benefit of version controlling your cluster manifests?

Trap 1: It allows you to host files on your local desktop

Version control stores manifests in a Git repository, not on a workstation; local hosting provides no history, diffing or collaboration. It is tempting because manifests are plain files you can keep anywhere, and a local directory would suffice for a single administrator experimenting alone without audit or rollback needs.

Trap 2: It replaces the need for a database

Git stores declarative YAML manifests and their revision history; it holds no application data and cannot substitute for a database. It is tempting because both Git and databases persist versioned records, but Git suits configuration and code, whereas stateful workloads still require a database for querying and transactions.

Trap 3: It speeds up node startup time

Version control tracks manifest revisions in Git; it never alters kubelet or container runtime behaviour, so node boot time is unchanged. The confusion arises because manifests are applied at cluster setup, yet startup latency is governed by image pulls and node provisioning, not by repository history.

A
It allows you to host files on your local desktop
Why it fails: Version control stores manifests in a Git repository, not on a workstation; local hosting provides no history, diffing or collaboration. It is tempting because manifests are plain files you can keep anywhere, and a local directory would suffice for a single administrator experimenting alone without audit or rollback needs.
B
It replaces the need for a database
Why it fails: Git stores declarative YAML manifests and their revision history; it holds no application data and cannot substitute for a database. It is tempting because both Git and databases persist versioned records, but Git suits configuration and code, whereas stateful workloads still require a database for querying and transactions.
C
It allows you to track, audit, and revert cluster changes
Git history records every manifest change with author and timestamp, so you can audit who altered the cluster and roll back to any prior commit. This directly satisfies the requirement to track, audit, and revert changes, unlike imperative kubectl edits that leave no declarative record.
D
It speeds up node startup time
Why it fails: Version control tracks manifest revisions in Git; it never alters kubelet or container runtime behaviour, so node boot time is unchanged. The confusion arises because manifests are applied at cluster setup, yet startup latency is governed by image pulls and node provisioning, not by repository history.

Question 3hardmultiple choice

You are troubleshooting a Flux controller that is not reconciling changes. The Git repository is updated, but the cluster remains unchanged. Which component should you inspect first to verify the 'automated pull-based reconciliation'?

Trap 1: The Kubernetes API server logs.

The API server only records requests made to it; Flux pulls from Git and pushes changes, so its logs cannot confirm whether reconciliation ran. API server logs are the right place when diagnosing rejected or failed API calls, not when verifying pull-based reconciliation behaviour.

Trap 2: The 'flux-system' namespace's 'kustomization.yaml' file.

A kustomization.yaml file declares desired resources; it is not the runtime component performing reconciliation. Inspecting it is tempting because it defines what Flux applies, but the controller that pulls and reconciles lives in the flux-system pods, whose logs reveal whether reconciliation is actually occurring.

Trap 3: The Git provider's webhook logs.

Webhook logs only show whether Git notified Flux of a commit; Flux's pull-based model polls Git regardless, so a missing webhook does not explain stalled reconciliation. Webhook logs are the correct first check when push-based notification is the intended trigger mechanism.

A
The Kubernetes API server logs.
Why it fails: The API server only records requests made to it; Flux pulls from Git and pushes changes, so its logs cannot confirm whether reconciliation ran. API server logs are the right place when diagnosing rejected or failed API calls, not when verifying pull-based reconciliation behaviour.
B
The 'flux-system' namespace's 'kustomization.yaml' file.
Why it fails: A kustomization.yaml file declares desired resources; it is not the runtime component performing reconciliation. Inspecting it is tempting because it defines what Flux applies, but the controller that pulls and reconciles lives in the flux-system pods, whose logs reveal whether reconciliation is actually occurring.
C
The Git provider's webhook logs.
Why it fails: Webhook logs only show whether Git notified Flux of a commit; Flux's pull-based model polls Git regardless, so a missing webhook does not explain stalled reconciliation. Webhook logs are the correct first check when push-based notification is the intended trigger mechanism.
D
The 'GitRepository' or 'Kustomization' custom resources.
Flux's GitRepository and Kustomization custom resources are the declarative objects that bind a Git source to cluster reconciliation. Inspecting their status reveals whether the source was fetched and whether the Kustomization applied it, directly verifying the automated pull-based reconciliation the stem describes.

Question 4mediummultiple choice

You are running Argo CD on a Kubernetes cluster. A developer reports that the argocd-application-controller repeatedly logs 'Failed to load target state: rpc error: code = Unknown desc = comparison error' for one Application, and the Application is stuck in the 'Unknown' health state. The cluster's outbound internet access is blocked, and the Application sources manifests from a private Git repository over HTTPS. Which component of Argo CD must you check first to resolve this?

Trap 1: The argocd-application-controller, because it performs the actual…

The application-controller does apply resources, but the error is about loading the target state, which happens before any apply. The controller talks to the Kubernetes API server, not to the private Git repository, so its connectivity is not the cause of this specific comparison error.

Trap 2: The argocd-server, because it serves the web UI and API and must…

The argocd-server handles the UI and API requests, but it does not fetch Git manifests for reconciliation. The repo-server is the component that clones and renders, so the argocd-server is not the first place to investigate this repository access failure.

Trap 3: The argocd-dex-server, because it provides authentication and the…

Dex handles identity and authentication for the Argo CD UI and CLI, not Git repository access or manifest rendering. An expired authentication token would prevent user login, but it would not produce a 'Failed to load target state' comparison error for an Application.

A
The argocd-application-controller, because it performs the actual Kubernetes API calls to apply resources and cannot connect to the API server.
Why it fails: The application-controller does apply resources, but the error is about loading the target state, which happens before any apply. The controller talks to the Kubernetes API server, not to the private Git repository, so its connectivity is not the cause of this specific comparison error.
B
The argocd-server, because it serves the web UI and API and must fetch the manifests on behalf of the controller.
Why it fails: The argocd-server handles the UI and API requests, but it does not fetch Git manifests for reconciliation. The repo-server is the component that clones and renders, so the argocd-server is not the first place to investigate this repository access failure.
C
The argocd-repo-server, because it is responsible for cloning the Git repository and generating the manifests, and it cannot reach the private repository.
The argocd-repo-server is the component that clones Git repositories and renders manifests. When outbound internet is blocked and the private Git repository is unreachable, reconciliation fails with a comparison error. Checking repo-server logs and network connectivity from its pod is the correct first step to resolve this scenario.
D
The argocd-dex-server, because it provides authentication and the Application may be failing due to an expired token.
Why it fails: Dex handles identity and authentication for the Argo CD UI and CLI, not Git repository access or manifest rendering. An expired authentication token would prevent user login, but it would not produce a 'Failed to load target state' comparison error for an Application.

Question 5hardmultiple choice

When troubleshooting a Kyverno policy, which command should you use to check if a specific resource complies with the policy?

Trap 1: kubectl get policies

kubectl get policies lists policy resources in the cluster; it never evaluates a named resource against those policies. It is tempting because listing is the natural first step when you want to see which policies exist, and it would be correct for inventorying installed policies rather than checking compliance.

Trap 2: kyverno test

kyverno test runs policies against local manifest files and test cases on your workstation, not against live cluster resources. It is tempting because it validates policy logic before deployment, and it would be correct when checking whether a policy behaves as intended during development.

Trap 3: kubectl describe policy

kubectl describe policy targets a policy object, not a workload, and reports no compliance evaluation for a specific resource. It is tempting because describe is the usual first step when inspecting any Kubernetes object, and it would be correct for reading a policy's own spec or status.

A
kubectl get policies
Why it fails: kubectl get policies lists policy resources in the cluster; it never evaluates a named resource against those policies. It is tempting because listing is the natural first step when you want to see which policies exist, and it would be correct for inventorying installed policies rather than checking compliance.
B
kyverno test
Why it fails: kyverno test runs policies against local manifest files and test cases on your workstation, not against live cluster resources. It is tempting because it validates policy logic before deployment, and it would be correct when checking whether a policy behaves as intended during development.
C
kubectl describe policy
Why it fails: kubectl describe policy targets a policy object, not a workload, and reports no compliance evaluation for a specific resource. It is tempting because describe is the usual first step when inspecting any Kubernetes object, and it would be correct for reading a policy's own spec or status.
D
kyverno apply
kyverno apply runs policy rules against given resource manifests locally, reporting pass or fail per resource without needing a cluster. This directly satisfies the stem's requirement to check whether a specific resource complies with a Kyverno policy.

Question 6mediummultiple choice

You are troubleshooting a multi-cluster Argo CD deployment where the 'staging' cluster is healthy but 'production' cluster is 'OutOfSync' despite having the same manifest source. Why might this happen?

Trap 1: The production cluster has a newer version of the Kubernetes API.

A newer Kubernetes API version on production would cause apply or schema errors, not an OutOfSync status, since Argo CD compares desired manifests against live state. API version differences matter when upgrading clusters or adopting new resource kinds.

Trap 2: The 'staging' cluster is using a different Argo CD instance.

Argo CD compares each cluster against the same Git revision, so a separate Argo CD instance for staging would not by itself make production OutOfSync. Different instances are used when clusters need independent configuration or access control, not shared manifest sources.

Trap 3: The Git repo is only cloned to the staging cluster.

Argo CD's application controller clones the Git repository itself and renders manifests before applying them to any cluster; clusters never clone repos. The staging cluster being healthy confirms the repo is reachable, so this cannot explain production's OutOfSync state.

A
The production cluster has a newer version of the Kubernetes API.
Why it fails: A newer Kubernetes API version on production would cause apply or schema errors, not an OutOfSync status, since Argo CD compares desired manifests against live state. API version differences matter when upgrading clusters or adopting new resource kinds.
B
A manual 'kubectl apply' was performed on the production cluster.
A manual `kubectl apply` on production mutates live resources outside Git, so Argo CD's diff detects drift between the desired manifest and actual cluster state, reporting `OutOfSync`. The staging cluster remains untouched and healthy, satisfying the stem's constraint that identical manifest sources yield divergent sync statuses.
C
The 'staging' cluster is using a different Argo CD instance.
Why it fails: Argo CD compares each cluster against the same Git revision, so a separate Argo CD instance for staging would not by itself make production OutOfSync. Different instances are used when clusters need independent configuration or access control, not shared manifest sources.
D
The Git repo is only cloned to the staging cluster.
Why it fails: Argo CD's application controller clones the Git repository itself and renders manifests before applying them to any cluster; clusters never clone repos. The staging cluster being healthy confirms the repo is reachable, so this cannot explain production's OutOfSync state.

Question 7mediummultiple choice

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

Trap 1: The Helm chart version

The Helm chart version affects which chart revision is rendered, not whether Flux can authenticate to a private GitHub repository, so the pull fails regardless of version. It is tempting because version mismatches cause many deployment faults, and would be correct if the source were reachable but the chart revision were wrong.

Trap 2: The cluster service account permissions

Cluster service account permissions govern what workloads inside the cluster may do; they play no part in Flux authenticating outbound to GitHub. It is tempting because RBAC misconfiguration is a frequent Kubernetes fault, and would be correct if the failure involved in-cluster API access rather than an external private repository.

Trap 3: The Kustomization path

The Kustomization path only locates manifests within an already-fetched source; it cannot authenticate to GitHub, so a wrong path yields missing files, not a pull failure. It is tempting because path errors are common Flux faults, and would be correct if the repository were reachable but the manifests sat elsewhere.

A
The Helm chart version
Why it fails: The Helm chart version affects which chart revision is rendered, not whether Flux can authenticate to a private GitHub repository, so the pull fails regardless of version. It is tempting because version mismatches cause many deployment faults, and would be correct if the source were reachable but the chart revision were wrong.
B
The cluster service account permissions
Why it fails: Cluster service account permissions govern what workloads inside the cluster may do; they play no part in Flux authenticating outbound to GitHub. It is tempting because RBAC misconfiguration is a frequent Kubernetes fault, and would be correct if the failure involved in-cluster API access rather than an external private repository.
C
The Kustomization path
Why it fails: The Kustomization path only locates manifests within an already-fetched source; it cannot authenticate to GitHub, so a wrong path yields missing files, not a pull failure. It is tempting because path errors are common Flux faults, and would be correct if the repository were reachable but the manifests sat elsewhere.
D
The GitRepository secret
The GitRepository custom resource references a Kubernetes secret holding the credentials or SSH key used to authenticate to the private repository. If that secret is missing, malformed, or lacks valid credentials, the operator cannot pull updates, producing exactly the described failure.