What does the Kyverno CLI command kyverno apply do with a policy and a manifest file?

## What the command is for A Kyverno policy is a Kubernetes custom resource whose rules match resources and then `validate`, `mutate` or `generate`. Once installed, those rules decide at admission — when someone submits an object to the API server — and they are also re-run in the background against objects that are already stored. Neither of those is a good place to find out that your brand-new rule matches the wrong kind or denies everything. `kyverno apply` is the escape hatch: it runs the policy engine as a local process over YAML files. ``` kyverno apply policy.yaml --resource deployment.yaml ``` You can pass several policies, several resources, or directories of each. The engine loads them, works out which rules match which resources, evaluates the rule bodies, and prints what happened. ## What comes back For each rule/resource pair you get one of a small set of outcomes: | result | meaning | | --- | --- | | pass | the rule matched the resource and the resource satisfied it | | fail | the rule matched and the resource violated it | | skip | the rule did not apply to this resource (match/exclude, preconditions) | | warn | a violation from a rule configured to advise rather than block | | error | the rule could not be evaluated — bad variable, missing context | plus a summary of the counts. The distinction between **fail** and **skip** is the one beginners misread: a long list of `skip` usually means your `match` block names a kind, a selector or an API group the resource does not have, so the rule you are proud of never ran at all. A wall of `error` usually means the rule references something that only exists at admission time. The process exits non-zero when there are failures, so it drops straight into CI: render your manifests, run the policies over them, fail the job. It can also emit its findings in the policy-report shape rather than as human text, which is handy when you want to feed the results into a dashboard instead of a terminal. For a `mutate` rule the CLI prints the resource after the patch, which is the fastest way to check that a mutation does what you meant rather than what you typed. ## Where it sits relative to the other two evaluation points Think of three places the same rule can run: 1. **The CLI, over files.** Before anything exists. No cluster, no state, no request. This is the dry run. 2. **Admission, over a request.** When someone submits an object. There is a requesting user, an operation, and for an update an old object; the answer is allow, deny or mutate. 3. **The background scan, over stored objects.** On an interval, against what is already in the cluster. Nobody is blocked; results are written into `PolicyReport` and `ClusterPolicyReport` objects. The CLI is the only one you can run on a laptop or in a pipeline that has no cluster, and the only one whose input you fully control. That is its value and also its limitation: it evaluates the file exactly as written, and neither of the other two positions ever sees exactly that. ## What a green run does and does not tell you It tells you the policy parses, the match block selects the resources you think it selects, and the rule body reaches the verdict you expect for the inputs you supplied. That is genuinely most of the mistakes. It does not tell you that admission will agree. The API server applies defaults to an object before validating it, and mutating admission — including Kyverno's own mutate rules and anyone else's webhooks — runs before validating admission, so the object that gets validated in a real cluster is not the file you handed the CLI. Rules that look up a ConfigMap, call the API, or read the requesting user have nothing to read offline unless you stub it with a values file. It also says nothing about objects already in the cluster. A rule can be perfectly green over every manifest in your repository while hundreds of stored objects violate it, because those objects were created before the rule existed and no one is resubmitting them. Finding those is the background scan's job, not the CLI's. ## Related tooling Alongside `apply` the CLI has `kyverno test`, which reads a test manifest declaring policies, resources and the result expected for each pair, and reports mismatches — the same engine, driven by declared expectations instead of eyeballed output. Designing those expectation sets is a testing discipline of its own; the point here is only that `apply` is the interactive form and `test` is the asserted form of the same offline evaluation.