I85PREP
⌘ K
Kyverno Certified Associate study materials
Kyverno Certified Associate study resources

Kyverno Certified Associate practice questions

One question at a time. Build your Kyverno Certified Associate understanding.

First 50 of 200 questions. Each one lists the choices, the correct answer, and an explanation. The checker at the top of this page saves progress in this browser when it is available.

Continue in the practice tool above to load more questions, 50 at a time.

Question 1Fundamentals of Kyverno

In Kyverno, what is the fundamental unit that expresses a policy rule, and in which API group is it defined?

  1. A ConstraintTemplate in the constraints.gatekeeper.sh API group
  2. A MutatingWebhookConfiguration in the kyverno.io API group
  3. A ClusterPolicy or Policy custom resource in the kyverno.io API group Correct answer.
  4. A ValidatingWebhookConfiguration in the admissionregistration.k8s.io API group

Explanation

Kyverno policies are Kubernetes custom resources named Policy (namespaced) or ClusterPolicy (cluster-scoped), both served from the kyverno.io API group. Kyverno itself installs and manages the underlying webhook configurations, so users do not author them directly.

Question 2Fundamentals of Kyverno

A platform team wants a policy that applies to resources in every namespace of the cluster. Which Kyverno resource should they create?

  1. A Policy named default in the kube-system namespace
  2. A Policy with an empty namespaceSelector
  3. A PolicyException referencing all namespaces
  4. A ClusterPolicy Correct answer.

Explanation

ClusterPolicy is cluster-scoped and its rules apply to matching resources across all namespaces. A namespaced Policy only applies to resources in its own namespace, and PolicyException exists to exempt resources rather than broaden scope.

Question 3Fundamentals of Kyverno

Which Kyverno rule type is used to block a resource from being created when it fails a check?

  1. verifyImages
  2. validate Correct answer.
  3. mutate
  4. generate

Explanation

The validate rule type evaluates an admission request against a condition or pattern and denies it when the check fails. Mutation changes the object, generate creates derived resources, and verifyImages checks image signatures.

Question 4Fundamentals of Kyverno

What does a Kyverno match block in a rule determine?

  1. Which resources the rule is evaluated against Correct answer.
  2. Which users are allowed to edit the policy
  3. Which namespaces are excluded from admission
  4. Which actions Kyverno takes after a match

Explanation

The match block selects the resource kinds, names, namespaces, and selectors to which a rule applies. Exclusion is handled separately by the exclude block, and the action is set by the rule type and its configuration.

Question 5Fundamentals of Kyverno

Which field in a Kyverno policy controls whether a failing rule blocks the request or merely reports the result?

  1. spec.rules[].match
  2. spec.rules[].validate.failureAction or the rule-level failureAction Correct answer.
  3. spec.background
  4. spec.rules[].preconditions

Explanation

failureAction (Audit or Enforce) determines whether a validation failure is only recorded in policy reports or actually denies the admission request. background controls reporting of existing resources, while match and preconditions gate evaluation.

Question 6Fundamentals of Kyverno

A team wants Kyverno to add a default label to every Pod that lacks it, without rejecting the request. Which rule type and behavior accomplish this?

  1. A mutate rule using a patchStrategicMerge or patchesJSON6902 operation Correct answer.
  2. A validate rule with failureAction set to Audit
  3. A verifyImages rule with a mutateDigest setting
  4. A generate rule with a synchronize flag

Explanation

Mutation rules modify the object during admission, so a missing label can be added before the object is persisted. Validation with Audit only reports and never changes the object, and generate creates separate resources.

Question 7Fundamentals of Kyverno

What is the purpose of the preconditions block in a Kyverno rule?

  1. To gate whether the rest of the rule is evaluated for a given request Correct answer.
  2. To specify which resources are generated
  3. To define the order in which rules run
  4. To declare which cluster roles may trigger the rule

Explanation

Preconditions are evaluated before the match and rule logic and act as a gate: if they are not satisfied, the rule is skipped for that request. They do not affect authorization, rule ordering, or generation targets.

Question 8Fundamentals of Kyverno

Which statement best describes how Kyverno differs from a policy engine that requires a separate general-purpose language runtime?

  1. Kyverno requires Rego policies to be compiled into ConfigMaps before use
  2. Kyverno policies must be written as Go plugins compiled into the API server
  3. Kyverno declares policies as Kubernetes resources and evaluates them natively without an external query language Correct answer.
  4. Kyverno only enforces policies at the kubelet level rather than at admission

Explanation

Kyverno is Kubernetes-native: policies are YAML custom resources using declarative match, exclude, and rule constructs, so no separate policy language or runtime is needed. Competing engines commonly rely on a general-purpose policy language such as Rego.

Question 9Fundamentals of Kyverno

In a Kyverno validate rule, what does the pattern block with an anchor such as `=(app)` signify?

  1. The field must be removed by mutation first
  2. The field is ignored during validation
  3. The field is optional and may be absent Correct answer.
  4. The field is required and must equal the literal string app

Explanation

In Kyverno patterns, a leading equals sign marks the key as optional, so validation passes whether or not the field exists. Without the anchor the field would be required to match the given value.

Question 10Fundamentals of Kyverno

Which of the following is the correct way to reference a ConfigMap value inside a Kyverno rule using a JMESPath variable?

  1. [[ configmap.data.key ]]
  2. %CONFIGMAP_KEY%
  3. {{ request.userInfo.username }} Correct answer.
  4. $(./configmap/data/key)

Explanation

Kyverno uses double curly braces to embed JMESPath expressions that read from the admission request, context, or variables. The other syntaxes are not part of Kyverno's variable substitution.

Question 11Fundamentals of Kyverno

A policy author wants a rule to read data from an existing ConfigMap at admission time. Which construct supplies that data?

  1. A generate block with a data field
  2. A context block with a configMap reference Correct answer.
  3. A preconditions block with a resource selector
  4. A validate block with a deny condition

Explanation

The context block lets a rule load external data, such as a ConfigMap or API resource, and expose it to variables used later in the rule. Generate, preconditions, and deny conditions do not fetch external data on their own.

Question 12Fundamentals of Kyverno

What does a Kyverno generate rule with synchronize set to true do for resources it creates?

  1. It pauses generation until the next admission request
  2. It keeps generated resources in sync with the source and restores or updates them if changed or deleted Correct answer.
  3. It copies the policy into every namespace
  4. It synchronizes the policy across all clusters in a fleet

Explanation

With synchronize enabled, Kyverno watches generated resources and reconciles them so they continue to reflect the trigger and data defined in the rule. It does not manage multi-cluster distribution or policy copying.

Question 13Fundamentals of Kyverno

Which Kyverno capability allows an administrator to exempt specific resources from a policy without editing the policy itself?

  1. A second ClusterPolicy with a lower priority
  2. AdmissionReview patches
  3. PolicyException resources Correct answer.
  4. Namespace annotations read by the policy

Explanation

PolicyException is a dedicated Kyverno resource that names the policy and the resources to exempt, keeping exceptions auditable and separate from the policy. Annotations and duplicate policies are not the supported exemption mechanism.

Question 14Fundamentals of Kyverno

Which rule type would an administrator use to require that all container images come from a trusted registry and carry a valid signature?

  1. generate
  2. validate
  3. verifyImages Correct answer.
  4. mutate

Explanation

verifyImages checks image references against attestors and keys to confirm signatures or attestations before admitting the workload. Validation can check registry strings but cannot verify cryptographic signatures.

Question 15Fundamentals of Kyverno

What is the role of the background field in a Kyverno rule?

  1. It determines whether the rule runs before or after mutation
  2. It controls whether Kyverno scans existing resources to produce policy reports Correct answer.
  3. It enables debug logging for the rule
  4. It sets the container image used by the Kyverno controller

Explanation

When background is true, Kyverno periodically evaluates existing resources against the rule and records results in policy reports. It has no effect on controller images, rule ordering, or logging.

Question 16Fundamentals of Kyverno

Which of the following correctly describes a Kyverno autogen behavior?

  1. Pod-level rules are automatically expanded to cover Pod controllers such as Deployments and StatefulSets Correct answer.
  2. Namespaced policies are automatically promoted to ClusterPolicies
  3. Rules are automatically converted into ValidatingAdmissionPolicies
  4. Policies are automatically translated into Rego

Explanation

Because Pod controllers create Pods indirectly, Kyverno autogen derives equivalent rules for workload controllers so that Pod-focused policies also apply to their templates. It does not translate policies into other engines or change policy scope.

Question 17Fundamentals of Kyverno

Which command-line tool is provided by the Kyverno project for testing policies locally before applying them to a cluster?

  1. kyverno apply Correct answer.
  2. kubectl kyverno lint
  3. kubectl policy test
  4. kyverno verify

Explanation

The Kyverno CLI's apply command evaluates policies against local resource manifests and reports pass or fail results without a cluster. Linting and testing are separate CLI subcommands, and kubectl has no built-in Kyverno policy tester.

Question 18Fundamentals of Kyverno

A rule uses a deny condition with `request.userInfo.username == 'system:serviceaccount:ci:builder'`. What does this condition do?

  1. It rewrites the caller identity to that service account
  2. It allows only that service account to bypass all policies
  3. It denies the request when the caller is that specific service account Correct answer.
  4. It generates a RoleBinding for that service account

Explanation

Deny conditions evaluate the admission request; when the expression is true, the request is rejected. Here the expression matches one service account identity, so requests from that account are denied rather than granted special privileges.

Question 19Fundamentals of Kyverno

Which statement about Kyverno mutation and validation ordering within a single policy is accurate?

  1. Validation rules run first and mutation is skipped if validation fails
  2. Mutation and validation always run in parallel on the original object
  3. Mutation rules are applied before validation rules so validation sees the mutated object Correct answer.
  4. Only one rule type may exist per policy

Explanation

Kyverno applies mutations before validations, allowing validation to evaluate the final object shape after defaults or patches are applied. This ordering is why a policy can both set a default and then enforce it.

Question 20Fundamentals of Kyverno

What is the primary purpose of Kyverno policy reports?

  1. To replace Kubernetes audit logs
  2. To provide metrics for the Kubernetes scheduler
  3. To store the YAML source of every policy
  4. To record the results of policy evaluations for resources in the cluster Correct answer.

Explanation

Policy reports summarize which resources pass or fail specific policies, giving visibility into compliance across existing workloads. They do not store policy source, replace audit logs, or feed scheduler metrics.

Question 21Fundamentals of Kyverno

A rule sets match to kinds Pod and namespaces with a label selector env=prod, and adds an exclude block for namespaces labeled exempt=true. Which resources are evaluated?

  1. All Pods in the cluster regardless of namespace labels
  2. Pods in exempt=true namespaces only
  3. Pods in prod-labeled namespaces that are not labeled exempt=true Correct answer.
  4. Pods in prod-labeled namespaces including those labeled exempt=true

Explanation

Match selects Pods in namespaces labeled env=prod, and exclude removes any namespace labeled exempt=true, so only the intersection of matched and non-excluded resources is evaluated. Exclude always subtracts from the matched set.

Question 22Fundamentals of Kyverno

Which field would you use in a Kyverno rule to compare a value against an external API resource fetched at admission time?

  1. A validate pattern anchor
  2. A context entry using an apiCall Correct answer.
  3. A generate clone source
  4. A mutate patchStrategicMerge

Explanation

The context block supports apiCall entries that query the Kubernetes API and expose the result to JMESPath variables. Patterns, clone sources, and strategic merge patches do not perform API lookups.

Question 23Fundamentals of Kyverno

What happens when two Kyverno policies both mutate the same field with conflicting values?

  1. The field is left unchanged
  2. Kyverno rejects the second policy at admission automatically
  3. The outcome depends on rule ordering and the last applied mutation can win, so authors should avoid conflicting mutations Correct answer.
  4. Kubernetes merges both values into a list

Explanation

Kyverno does not provide a global conflict-resolution priority; conflicting mutations can produce order-dependent results. Authors should design policies so that mutations to the same field do not collide.

Question 24Fundamentals of Kyverno

Which of the following best explains why Kyverno rules commonly target Pods even when users deploy Deployments?

  1. Kyverno converts Deployments into Pods before admission
  2. Pods are the only resource kind Kyverno can match
  3. Pod templates are where container-level settings live, and autogen extends Pod rules to controllers Correct answer.
  4. Deployments cannot be validated by admission webhooks

Explanation

Container security settings such as image, resources, and security context live in the Pod template, so Pod-focused rules are natural; autogen then extends them to the controllers that create Pods. Kyverno can match many kinds, and it does not rewrite Deployments into Pods.

Question 25Fundamentals of Kyverno

An administrator wants to install Kyverno in high-availability mode. Which consideration is most relevant to the fundamentals of its architecture?

  1. Converting ClusterPolicies into namespaced Policies
  2. Running multiple controller replicas so admission webhooks remain available if one pod fails Correct answer.
  3. Disabling all webhooks to reduce latency
  4. Removing policy reports to save storage

Explanation

Kyverno runs as controllers behind dynamically managed webhooks, so multiple replicas provide resilience for admission traffic. Disabling webhooks or removing reports would eliminate enforcement and visibility rather than improve availability.

Question 26Fundamentals of Kyverno

In Kyverno, which resource kind is the cluster-scoped object that holds one or more rules and is evaluated by the admission controller?

  1. PolicyException
  2. CleanupPolicy
  3. ClusterPolicy Correct answer.
  4. PolicyReport

Explanation

A ClusterPolicy is the cluster-scoped Kyverno resource that carries validation, mutation, generation, or image verification rules and is applied to matching resources cluster-wide. The namespaced equivalent is Policy, which limits the policy's reach to its own namespace.

Question 27Fundamentals of Kyverno

A rule must apply only to Pods in namespaces labeled `team=payments`. Which match structure expresses that scope?

  1. match.any.resources.kinds Pod plus a namespaceSelector on team=payments Correct answer.
  2. preconditions with a key of `{{ request.namespace }}` equal to payments
  3. match.resources.names Pod plus a labelSelector on team=payments
  4. exclude.resources.kinds Pod plus a namespaceSelector on team=payments

Explanation

Namespace scoping is expressed with namespaceSelector inside the match block, combined with the target kinds under resources. The selector is evaluated against the labels of the namespace that contains the incoming resource.

Question 28Fundamentals of Kyverno

Which statement describes how a Kyverno validate rule with `failureAction: Audit` affects an incoming request?

  1. The request is admitted and the violation is recorded in a policy report Correct answer.
  2. The request is rejected and the API server returns an error to the client
  3. The request is admitted but the offending field is silently removed
  4. The rule is skipped entirely until the policy is set to Enforce

Explanation

Audit mode lets the resource through while Kyverno records the failed rule in policy reports so operators can review violations before enforcing. Enforcement, by contrast, blocks the admission request with a failure message.

Question 29Fundamentals of Kyverno

A mutate rule must set a label only when the incoming Pod has no `cost-center` label at all. Which JMESPath-based condition achieves this?

  1. `{{ request.operation }}` equal to CREATE
  2. `{{ length(request.object.metadata.labels) }}` greater than zero
  3. `{{ request.object.metadata.labels.'cost-center' || '' }}` compared to an empty string Correct answer.
  4. `{{ request.object.metadata.labels.'cost-center' }}` compared to `null` using a not-equals test

Explanation

A precondition that compares the resolved label value to an empty string is true when the label is absent, because the JMESPath expression yields an empty result. The patch is then applied only to Pods missing that label.

Question 30Fundamentals of Kyverno

Which Kyverno rule type is used to verify that container images are signed by a trusted key before the Pod is admitted?

  1. validate
  2. mutate
  3. verifyImages Correct answer.
  4. generate

Explanation

The verifyImages rule type checks image signatures and attestations against configured keys or certificate authorities and can reject unsigned or untrusted images. It is a distinct rule type rather than a validate pattern.

Question 31Fundamentals of Kyverno

What does the `background` field control in a Kyverno rule?

  1. Whether Kyverno writes results to a PolicyReport
  2. Whether the rule runs during admission of new requests
  3. Whether the rule is applied to resources that already exist in the cluster Correct answer.
  4. Whether the rule uses cached API data instead of live lookups

Explanation

Setting background to true allows Kyverno's background controller to scan existing resources and report or act on them, not just newly admitted ones. Setting it to false restricts the rule to admission-time evaluation.

Question 32Fundamentals of Kyverno

An administrator wants to exempt a specific set of Deployments from a policy without modifying the policy itself. Which mechanism should be used?

  1. Create a PolicyException that names the policy and the matching resources Correct answer.
  2. Add an exclude block to every rule in the policy
  3. Add a precondition to each rule that checks the resource name
  4. Set the policy's failureAction to Audit

Explanation

A PolicyException resource references the policy or policies to exempt and lists the resources that qualify, keeping the exemption separate from the policy definition. This allows central teams to control the policy while allowing scoped exceptions.

Question 33Fundamentals of Kyverno

A generate rule creates a ConfigMap in each new namespace and must keep it in sync when the source data changes. Which setting is required?

  1. `generateExisting: true` on the generate rule
  2. `synchronize: true` on the generate rule Correct answer.
  3. `background: true` on the generate rule
  4. `failureAction: Enforce` on the generate rule

Explanation

With synchronize set to true, Kyverno tracks the downstream resource it generated and updates it when the source data or the rule changes. Without it, the generated resource is created once and left alone.

Question 34Fundamentals of Kyverno

A Deployment is submitted, but the policy targets Pods. Why does the rule still take effect on the resulting Pods?

  1. The API server rewrites the Deployment into a Pod for validation
  2. Kyverno autogen creates equivalent rules for the Pod template controller kinds Correct answer.
  3. Pod policies are applied only after the Pod is scheduled to a node
  4. Kyverno converts the Deployment into a Pod before admission

Explanation

Kyverno's autogen feature derives rules for workload controllers such as Deployments, StatefulSets, and DaemonSets from a Pod-targeted rule, so the Pod template is evaluated at admission. This means authors can write one Pod rule and have it cover the common controllers.

Question 35Fundamentals of Kyverno

A rule must be limited to requests made by a specific service account. Which request attribute should the condition inspect?

  1. `request.namespace`
  2. `request.object.metadata.name`
  3. `request.userInfo.username` Correct answer.
  4. `request.operation`

Explanation

The identity of the caller is exposed through request.userInfo, whose username for a service account takes the form system:serviceaccount:<namespace>:<name>. Comparing that value lets a rule key on the requesting identity rather than the resource content.

Question 36Fundamentals of Kyverno

Two policies both mutate the same field of a Pod with different values. What is the most accurate description of how Kyverno resolves this?

  1. The API server rejects the Pod because the patches conflict
  2. The last policy applied alphabetically wins and the other is ignored
  3. Kyverno merges both values into a list on the field
  4. Kyverno applies mutation rules in order and the resulting value depends on rule ordering and policy application sequence Correct answer.

Explanation

Mutation rules are applied in sequence, so when two rules touch the same field the later application can overwrite the earlier one, making ordering and policy design important. Authors should avoid overlapping mutations or use preconditions to make intent explicit.

Question 37Installation, Configuration, and Upgrades

When installing Kyverno with Helm, which chart repository does the project publish its charts to?

  1. https://charts.jetstack.io
  2. https://kubernetes-charts.storage.googleapis.com
  3. https://kyverno.io/charts/stable
  4. https://kyverno.github.io/kyverno/ Correct answer.

Explanation

The Kyverno project publishes its Helm charts through GitHub Pages at kyverno.github.io/kyverno, so you add that repository and install the kyverno/kyverno chart. The other URLs are either unrelated projects or not real chart endpoints.

Question 38Installation, Configuration, and Upgrades

Which command installs Kyverno into the cluster using Helm with the release name kyverno in the kyverno namespace?

  1. helm install kyverno kyverno/kyverno --namespace kyverno --create-namespace Correct answer.
  2. helm upgrade --install-chart kyverno kyverno -n kyverno
  3. kubectl helm install kyverno/kyverno -n kyverno
  4. helm apply kyverno/kyverno --namespace kyverno

Explanation

The standard Helm install form is helm install <release> <chart> with flags for the target namespace. Adding --create-namespace lets Helm create the kyverno namespace if it does not already exist.

Question 39Installation, Configuration, and Upgrades

Which installation method applies Kyverno's manifests directly from a published release YAML without using Helm?

  1. kubectl run kyverno --image=kyverno/kyverno
  2. kustomize build https://github.com/kyverno/kyverno/charts
  3. kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/main/deploy.yaml
  4. kubectl create -f https://github.com/kyverno/kyverno/releases/download/<version>/install.yaml Correct answer.

Explanation

Kyverno publishes a consolidated install.yaml for each release, which can be applied with kubectl create or apply. This installs the CRDs, controllers, and supporting resources in one step without Helm.

Question 40Installation, Configuration, and Upgrades

Which Kyverno component evaluates admission requests and applies mutate and validate rules?

  1. The reports controller
  2. The admission controller Correct answer.
  3. The background controller
  4. The cleanup controller

Explanation

The admission controller runs as a validating and mutating webhook and is responsible for evaluating policies against incoming API requests. The other controllers handle background scanning, cleanup, and report aggregation respectively.

Question 41Installation, Configuration, and Upgrades

Which controller is responsible for generating PolicyReports and ClusterPolicyReports from policy results?

  1. The reports controller Correct answer.
  2. The cleanup controller
  3. The admission controller
  4. The background controller

Explanation

The reports controller watches policy results and assembles them into PolicyReport and ClusterPolicyReport resources. It does not perform admission enforcement itself.

Question 42Installation, Configuration, and Upgrades

Which CustomResourceDefinition must exist before you can create a ClusterPolicy object?

  1. clusterpolicies.kyverno.io Correct answer.
  2. clusteradmissionpolicies.kyverno.io
  3. policies.kyverno.io
  4. policyreports.wgpolicyk8s.io

Explanation

ClusterPolicy is a cluster-scoped Kyverno resource whose CRD is clusterpolicies.kyverno.io. Installing Kyverno applies this CRD, which must exist before ClusterPolicy objects can be stored.

Question 43Installation, Configuration, and Upgrades

Which Helm value is used to change the number of admission controller replicas during installation?

  1. --set controller.replicaCount=3
  2. --set kyverno.admission.replicas=3
  3. --set webhook.replicas=3
  4. --set admissionController.replicas=3 Correct answer.

Explanation

In the Kyverno Helm chart the admission controller is configured under the admissionController key, so its replica count is set with admissionController.replicas. The other paths do not correspond to chart values.

Question 44Installation, Configuration, and Upgrades

After installing Kyverno, which command confirms that the admission controller Deployment became available?

  1. kubectl get validatingwebhookconfiguration
  2. kubectl get clusterpolicy -A
  3. kubectl get crd policies.kyverno.io
  4. kubectl get deployment -n kyverno Correct answer.

Explanation

Listing Deployments in the kyverno namespace shows the controller workloads and their ready replica counts, which confirms the admission controller started. The other commands inspect policies, webhook configs, or CRDs rather than workload readiness.

Question 45Installation, Configuration, and Upgrades

A cluster runs Kyverno in high-availability mode. Which setting ensures the admission webhook keeps working if one controller Pod is lost?

  1. Setting the webhook timeoutSeconds to 1
  2. Running the admission controller with multiple replicas and a failurePolicy of Fail Correct answer.
  3. Disabling the webhook and relying on background scans only
  4. Setting the webhook failurePolicy to Ignore and running a single replica

Explanation

Multiple admission controller replicas keep the webhook service backed by a healthy endpoint, and failurePolicy Fail enforces policy even if the webhook is briefly unreachable. Single replicas or Ignore reduce resilience or enforcement.

Question 46Installation, Configuration, and Upgrades

You must install Kyverno so that it only evaluates resources in the namespace team-a. Which configuration approach is appropriate?

  1. Install Kyverno into team-a and delete the other namespaces
  2. Set the Helm value config.webhooks to exclude all namespaces except team-a Correct answer.
  3. Set the Helm value policyNamespace to team-a
  4. Set the Helm value admissionController.namespaceSelector

Explanation

The Kyverno chart exposes webhook namespace filtering through config.webhooks, where you can set namespaceSelector or exclude namespaces. This limits which resources are sent to the admission controller without affecting unrelated namespaces.

Question 47Installation, Configuration, and Upgrades

Which Helm value disables the Kyverno cleanup controller during installation?

  1. --set controller.cleanup=false
  2. --set cleanupController.enabled=false Correct answer.
  3. --set features.cleanupController=false
  4. --set cleanup.enabled=false

Explanation

Each Kyverno controller has its own enabled flag in the chart, so the cleanup controller is toggled with cleanupController.enabled. The other keys are not defined in the chart.

Question 48Installation, Configuration, and Upgrades

An upgrade of Kyverno via Helm fails because the CRDs were not updated. Which action resolves this?

  1. Downgrade the Helm client to an older version
  2. Delete the kyverno namespace and reinstall from scratch
  3. Apply the CRD manifests from the target release before or alongside the Helm upgrade Correct answer.
  4. Set --set crds.install=false and retry the upgrade

Explanation

Helm does not automatically upgrade CRDs stored in the crds directory, so they must be applied separately from the target release manifests. Applying them before the chart upgrade ensures new fields are accepted.

Question 49Installation, Configuration, and Upgrades

Which command upgrades an existing Kyverno Helm release to a newer chart version while keeping existing values?

  1. helm install --upgrade kyverno kyverno/kyverno -n kyverno
  2. helm upgrade kyverno kyverno/kyverno -n kyverno Correct answer.
  3. kubectl apply -f kyverno-install.yaml
  4. helm update kyverno kyverno/kyverno -n kyverno

Explanation

helm upgrade takes the release name and chart and applies the new chart version, reusing previously supplied values unless overridden. This is the standard path for upgrading a Helm-managed Kyverno installation.

Question 50Installation, Configuration, and Upgrades

Before upgrading Kyverno to a new minor version, which step best protects existing policies?

  1. Disable the admission controller permanently before upgrading
  2. Delete all policies so the upgrade cannot conflict with them
  3. Export existing Policy and ClusterPolicy resources and review the release notes for breaking changes Correct answer.
  4. Convert all ClusterPolicies to namespaced Policies

Explanation

Backing up policy resources and reading the release notes lets you detect removed fields or changed behavior before the upgrade. Deleting or converting policies is destructive and unnecessary.