Automation and Tooling: KCSA practice questions

Automation and tooling is the part of compliance that runs without a person in the loop. Writing a rule in a policy document does not stop anyone from creating a privileged pod; a control that is evaluated on every API request, or a scanner that inspects the cluster continuously, does. The tools in this topic fit into a small number of roles, and recognizing the role matters more than memorizing product names.

The first role is preventive enforcement at admission. An admission controller intercepts a request to the API server after it has been authenticated and authorized but before the object is persisted. Mutating controllers run first and may change the request; validating controllers run second and may only accept or reject it. If any controller in either phase rejects the request, the whole request fails. Admission controllers act on create, update, delete and connect requests; they cannot block reads. Built-in plugins such as PodSecurity and ResourceQuota cover common rules, and MutatingAdmissionWebhook and ValidatingAdmissionWebhook let external policy engines take part.

Two policy engines appear often. OPA Gatekeeper describes itself as a validating and mutating webhook that enforces CRD-based policies executed by Open Policy Agent: a ConstraintTemplate defines a reusable policy and a Constraint instantiates it with parameters. Kyverno takes a Kubernetes-native approach in which policies are themselves Kubernetes resources written in YAML and CEL, so no new language is required, and they can be enforced as an admission controller, from a CLI scanner or at runtime. Kyverno rules can validate, mutate, generate or clean up resources, and can verify container images and their metadata for supply chain checks.

The second role is detective: finding what is already wrong. Admission only sees new requests, so objects created before a policy existed are not covered. Gatekeeper's audit function reports existing resources that violate a policy, and Kyverno reports results in the OpenReport format. Configuration benchmarks such as the CIS Kubernetes Benchmark are checked by scanners against node and control plane settings rather than individual objects.

The third role is runtime detection. Falco reads Linux kernel system call events, optionally adds other data sources through plugins, enriches events with container and Kubernetes metadata, and compares them with YAML rules; when a rule matches it raises an alert to stdout, a file, syslog, a program or an HTTP endpoint. Falco is a graduated CNCF project. This covers behavior that no manifest reveals, such as a shell spawned inside a running container.

Infrastructure as Code ties the roles together. When manifests and policies live in version control, every change is reviewed and repeatable, the same policy can be evaluated in a pipeline before anything reaches the cluster, and the history doubles as an audit trail.