Free KCA practice test: 30 questions with answers

A validate rule with a pattern can require the runAsNonRoot setting, so non-compliant Pods are rejected at admission. Generate creates other objects, mutate changes objects rather than deleting them, and cleanup removes resources on a schedule instead of blocking creation.

A mutate rule can fill in missing fields, and an add-if-absent style patch keeps values users have already set. Validate rules reject rather than fill in defaults, generate creates new objects, and cleanup deletes resources on a schedule.

The synchronize field on a generate rule tells Kyverno to keep generated resources in sync with their source. Audit mode only affects how validation results are reported, a mutate rule does not copy ConfigMaps, and autogen extends Pod rules to pod controllers rather than creating copies.

A verifyImages rule looks up signatures for matching image references and checks them against the keys or attestors the rule lists. A name list cannot prove who signed an image, cleanup rules delete Kubernetes resources rather than registry images, and renaming a tag does not establish a signature.

Context entries load extra data, such as the result of an API call, that rule conditions and variables can use. The other options describe audit logging, a bypass of the admission webhook, and a change to matching, none of which is what an API call context entry does.

A validate rule in a Kyverno policy can match Namespace resources at admission and reject any request whose object lacks the label. A ConfigMap does not enforce anything by itself, a NetworkPolicy controls network traffic rather than object metadata, and a ResourceQuota limits resource consumption, not labels.

Validate rules evaluate the object and allow or reject the request (or only report the result in audit mode), whereas mutate rules patch the object, for example to add a default label. Option A reverses the roles of unrelated rule types, B swaps validate and mutate, and D is wrong because both rule types can target any kind named in their match block.

Every Kubernetes object manifest declares apiVersion, kind, and metadata, which identify the resource type and its name. The status field is written by the system rather than authored, rules is nested under spec rather than at the top level, and data is a ConfigMap-specific field.

The Kubernetes API server calls Kyverno's admission webhooks during a request, and Kyverno can allow, deny, or patch the object before it is stored. Kyverno does not replace etcd, does not schedule Pods, and is not a per-Pod sidecar that inspects traffic.

Kubernetes runs mutating admission before object schema validation and validating admission, so the default label is already present when the validating policy runs. The other options describe an order or behaviour that does not exist in the admission chain.

The official Helm chart accepts a values file, which can be versioned and reused for repeatable installs. Manual edits leave no reviewable record, a systemd unit would run the controller outside Kubernetes, and kyverno apply evaluates policies against resources rather than installing controllers.

Custom resource definitions teach the API server a new resource type and its schema, which is what allows ClusterPolicy objects to be stored and validated. CRDs do not hold copies of admitted resources, kubectl needs them just as Helm does, and the offline CLI does not depend on CRDs being installed in a cluster.

A forbidden error points to RBAC, so the Kyverno controller's service account must be granted permission to create the target kind. NetworkPolicy is a valid kind, generate rules are not limited to ConfigMaps, and Audit mode reports violations rather than blocking controller writes.

Admission requests are sent to the webhook service, so with several replicas one failed Pod does not stop admission decisions. Policies are stored as cluster objects rather than inside each replica, replicas do not shard background scans, and the API server must still call the webhook.

The kyverno/kyverno chart name resolves only after the chart repository has been added with helm repo add (pointing at the Kyverno project's chart repository) and refreshed with helm repo update. The Kyverno CLI does not manage Helm repositories, Helm does not need hand-made CRDs to find a chart, and there is no scheduler plugin involved.

kyverno apply evaluates policies against resource files offline and reports the results, so no cluster is needed. kyverno jp only evaluates JMESPath expressions, kyverno test checks results against expectations in a test file rather than deploying anything, and kyverno version only reports the CLI version.

A Kyverno test file maps resources and policies to expected results, and kyverno test compares the actual outcomes with those expectations. The file does not install anything, hold signing keys, or store report history.

The jp subcommand works as a JMESPath playground in the terminal, so an author can check a query before embedding it in a rule. The other subcommands run policies or report versions, and none of them evaluates an arbitrary expression for the author.

Homebrew and the binaries published on the project's GitHub releases are standard ways to put the CLI on a workstation. Helm installs workloads into a cluster rather than a CLI on a laptop, and an admission controller container image is not an executable CLI.

kyverno apply runs policies against resource files offline and outputs the mutated resources together with the results. The jp subcommand evaluates queries rather than patching files, an empty test file does not describe changes, and the version subcommand only prints the CLI version.

Background scanning evaluates resources that already exist, and the results appear in policy reports. Admission webhooks only see requests as they arrive, the test command works on local files rather than the live cluster, and a cleanup policy deletes resources instead of reporting on them.

The match and exclude blocks decide which resources a rule evaluates, so they handle Namespace and label selection. The other options change the object, change the reporting mode for all Deployments, or create resources, and none of them selects resources.

Preconditions are conditions evaluated before a rule's checks and can use values such as the number of containers. The background field controls whether existing resources are scanned, exclude lists resources to skip rather than counts, and failurePolicy is a webhook setting rather than a rule field.

Audit mode admits the request and records the violation, which suits a rollout period. Enforce would reject the legacy requests, a mutate rule changes workloads rather than reporting on them, and a cluster-wide exception would stop the rule from reporting anything at all.

The match and exclude blocks define the scope of a rule, deciding which resources are checked and which are skipped. The message field only sets the text shown on failure, and synchronize applies to generate rules, so neither one limits which resources a rule evaluates.

The reports controller writes PolicyReport resources that contain per-rule results, and namespaced reports are grouped by Namespace. PolicyException resources exempt resources rather than reporting failures, and the other two options do not produce compliance summaries.

A PolicyException names the policy and rules it exempts and selects matching resources, leaving the policy itself unchanged. Exceptions do not switch enforcement modes cluster-wide, and they are ordinary resources that users create rather than entries inside reports.

ClusterPolicyReport is the cluster-scoped counterpart to PolicyReport, and it carries results for cluster-scoped resources. A namespaced PolicyReport only covers resources in its own Namespace, while PolicyException and CleanupPolicy do not store scan results.

A PolicyException can reference a specific policy and rule and select a single resource, so the rest of the cluster stays enforced. Audit mode for every Deployment removes enforcement for all workloads, an annotation on a Namespace is not a documented way to disable policies, and cleanup would delete the workload that the team needs to keep.

Kyverno exposes Prometheus metrics, including counts of policy results and admission requests, which suit dashboards and alerts. Manifest copies, signing keys, and Helm values are not what the metrics endpoint publishes.