CKS Monitoring, Logging and Runtime Security Practice Question
You are configuring Kubernetes audit logging. You want to log all requests to the `secrets` resource in the `kube-system` namespace at the `RequestResponse` level, while logging all other requests at the `Metadata` level. Which audit policy configuration achieves this?
⚠ Common exam trap
Kubernetes often tests the order of audit policy rules and the specific resource/namespace matching syntax, where candidates mistakenly think a wildcard resource rule can be overridden by a later rule, or confuse the `Metadata` and `RequestResponse` levels.
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
✓
rules: [- level: RequestResponse, resources: [group: '', resources: [secrets]], namespaces: [kube-system], - level: Metadata]
It defines an audit policy rule that matches requests to the `secrets` resource (core API group, empty string) in the `kube-system` namespace and sets the audit level to `RequestResponse`, which logs both the request metadata and the response body. The subsequent `- level: Metadata` rule acts as a catch-all for all other requests, logging only metadata. Audit policy rules are evaluated in order, and the first matching rule applies, so the specific rule for secrets must come before the general rule.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
rules: [- level: RequestResponse, resources: [group: '', resources: [*]], - level: Metadata]
Why it's wrong here
The first rule matches every resource at RequestResponse, so secrets never reach the Metadata rule; audit rules evaluate in order with first match winning. Ordering a broad catch-all first is the correct pattern when every request should share one level.
- ✓
rules: [- level: RequestResponse, resources: [group: '', resources: [secrets]], namespaces: [kube-system], - level: Metadata]
Why this is correct
Audit policy rules are evaluated in order, first match wins. Placing the RequestResponse rule for secrets in kube-system first captures that resource at full detail, while the trailing Metadata rule acts as the catch-all for every other request, satisfying both logging requirements in one policy.
- ✗
rules: [- level: Metadata, resources: [group: '', resources: [secrets]], namespaces: [kube-system], - level: RequestResponse]
Why it's wrong here
Metadata is less verbose than RequestResponse, so secrets in kube-system are logged without request or response bodies, failing the requirement. This ordering is correct when you want a specific noisy resource downgraded while everything else is captured fully.
- ✗
rules: [- level: Metadata, resources: [group: '', resources: [secrets]], namespaces: [kube-system], omitStages: [RequestReceived], - level: RequestResponse]
Why it's wrong here
The first rule matches secrets in kube-system but sets level Metadata, so RequestResponse logging never applies to those requests; the trailing rule only catches everything else. Swapping the levels would work. Metadata-only auditing suits low-risk, high-volume resources where you need request identity but not payloads.
Go deeper
Related to this question
About these practice questions
This CKS question is part of Courseiva's 845-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
1 more way this is tested on CKS
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. You need to configure Kubernetes audit logging to log all requests to the 'secrets' resource at the 'RequestResponse' level, but only log requests from the 'kube-system' namespace. Which audit policy rule is correct?
hard- ✓ A.- level: RequestResponse resources: - apiGroup: "" resources: ["secrets"] namespaces: ["kube-system"]
- B.- level: RequestResponse resources: - group: "" resources: ["secrets"] namespaces: ["kube-system"]
- C.- level: RequestResponse resources: - group: "" resources: ["secrets"] namespace: ["kube-system"]
- D.- level: RequestResponse resources: - group: "" resources: ["secrets"] namespace: ["kube-system"]
Why A: The correct audit policy rule uses 'apiGroup' for the API group and 'namespaces' to specify the namespace. Option A correctly specifies these fields: 'apiGroup: ""' for the core API group and 'namespaces: ["kube-system"]'. Option B incorrectly uses 'group' instead of 'apiGroup', which is not a valid field. Option C uses 'group' and the singular 'namespace', both incorrect. Option D uses 'group' and the singular 'namespace'. Therefore, only option A is valid.
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.