CKS Monitoring, Logging and Runtime Security Practice Question
Which Kubernetes resource is used to define audit logging configuration?
⚠ Common exam trap
Many candidates confuse the audit policy configuration mechanism (a static YAML file passed via `--audit-policy-file`) with a Kubernetes resource like a ConfigMap or CRD, because many other Kubernetes configurations (e.g., kubelet config, scheduler policies) are indeed stored in ConfigMaps or custom resources.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
A YAML file specified via `--audit-policy-file`
Kubernetes audit logging configuration is defined in a YAML file that specifies the audit policy rules, and this file is passed to the kube-apiserver via the `--audit-policy-file` command-line flag. This YAML file defines which events (e.g., requests to the API server) should be logged and at what level (e.g., Metadata, Request, RequestResponse). No other Kubernetes resource or CRD is used for this purpose.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
A YAML file specified via `--audit-policy-file`
Why this is correct
The kube-apiserver's audit logging behavior is governed by a YAML policy file located on the apiserver's host filesystem, whose path is passed via the `--audit-policy-file` startup flag. This file is not a Kubernetes API resource; it is a plain configuration file containing a set of rules that map requested attributes (verbs, resources, namespaces, users) to audit levels: None, Metadata, Request, or RequestResponse. The apiserver reads this file at initialization and applies it to all incoming API requests, so changing the policy requires editing the file and restarting the apiserver.
- ✗
PodSecurityPolicy
Why it's wrong here
PodSecurityPolicy is an admission controller resource that historically enforced constraints on pod security contexts, such as whether a pod could run privileged or use host namespaces. It was deprecated and removed in Kubernetes v1.25, and it has nothing to do with auditing or logging. Audit logging concerns the recording of API server request metadata and payloads, not the enforcement of pod-level security policies.
- ✗
ConfigMap in kube-system
Why it's wrong here
A ConfigMap placed in the kube-system namespace is a standard Kubernetes resource for storing key-value configuration data. However, the kube-apiserver does not consume the audit policy from a ConfigMap; it requires a local file path supplied with `--audit-policy-file`. Even if you mount a ConfigMap as a volume into the apiserver's pod, the apiserver only sees a file on disk, and the ConfigMap itself is never interpreted as the audit policy.
- ✗
AuditPolicy CRD
Why it's wrong here
In upstream Kubernetes, there is no built-in `AuditPolicy` Custom Resource Definition (CRD). The audit policy is not represented as a CRD; it is purely a YAML file on the apiserver's filesystem. While you could theoretically create your own CRD named AuditPolicy, the apiserver would have no built-in logic to read or apply it for auditing, so it would not satisfy the requirement.
Go deeper
Related to this question
About these practice questions
One of 845 original CKS practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CKS practice question is part of Courseiva's free CNCF certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CKS exam.