CKS Monitoring, Logging and Runtime Security Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Audit logging can be enabled without restarting the API server

  Why it's wrong here

  Enabling audit logging requires restarting the kube-apiserver because the audit policy file is parsed and loaded into memory only at process startup. The --audit-policy-file and related flags such as --audit-log-path cannot be changed dynamically, so the statement that audit logging can be enabled without a restart is false. Any change to audit configuration necessitates a controlled API server restart, which has operational implications for clusters.

• ✓

  Audit stages include 'RequestReceived', 'ResponseStarted', 'ResponseComplete', and 'Panic'

  Why this is correct

  The Kubernetes audit system defines exactly four stages at which an event can be recorded: RequestReceived, ResponseStarted, ResponseComplete, and Panic. RequestReceived occurs immediately when the API server receives a request, ResponseStarted happens after response headers are sent but before the response body, ResponseComplete after the full response is sent, and Panic if a panic occurs while handling the request. Because these stages are captured in the audit policy rules, operators can choose to log only certain stages, such as logging RequestReceived for all requests and ResponseComplete for mutating requests.

• ✓

  The audit policy file is passed to the API server via the --audit-policy-file flag

  Why this is correct

  To enable audit logging, the kube-apiserver must be started with the --audit-policy-file flag pointing to a YAML or JSON file that contains the audit policy rules. This flag tells the API server which file to load at startup, and without it the API server will not generate audit events. The audit policy file defines rule order, levels, stages, and namespaces, making it the central configuration for audit behavior.

• ✗

  The 'Request' level logs both request and response bodies

  Why it's wrong here

  The audit policy 'Request' level logs only the request body; it does not include the response body. To capture both request and response bodies, the 'RequestResponse' level must be used, while the 'Response' level captures only the response body. The 'Request' level is commonly used when the response may contain sensitive data that should not be logged, so the statement claiming it logs both is incorrect.

• ✗

  The 'Metadata' level logs the request body

  Why it's wrong here

  The 'Metadata' audit level logs only a subset of the audit event such as user, verb, resource, namespace, and response status code, but explicitly omits request and response bodies. Its purpose is to reduce log volume and avoid capturing sensitive payloads while still providing an audit trail of who did what. There is no level that logs only the request body; at minimum you need 'Request' level, so the statement is false.

Go deeper

Related to this question