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-log-path

  Why it's wrong here

  This flag designates the file where audit events should be appended, but it only configures the log backend destination. Merely setting it does not cause the kube-apiserver to record any audit data; the apiserver requires a valid audit policy file to determine which events to capture. Without --audit-policy-file, no events are generated, so the configured log file remains empty regardless of the path provided.

• ✗

  --audit-webhook-config-file

  Why it's wrong here

  This flag points to a kubeconfig-style configuration that defines an external HTTP webhook for receiving audit events. While it is a legitimate backend for streaming audit logs to an external service, it cannot activate audit logging by itself. The kube-apiserver only emits audit events after an audit policy is loaded via --audit-policy-file; until then, the webhook backend has no data to send.

• ✗

  --feature-gates=Audit=true

  Why it's wrong here

  This option is based on a misconception that audit logging is an experimental feature behind a feature gate. In reality, audit logging has been stable since Kubernetes 1.12 and is controlled by the presence of an audit policy file, not by a feature gate. Passing an unknown gate named "Audit" would be ignored or rejected by the apiserver and would certainly not enable any audit functionality.

• ✓

  --audit-policy-file

  Why this is correct

  This is the correct flag that actually enables audit logging. It specifies the path to a YAML file containing a list of rules that define, in order, which requests (based on user, verb, resource, and phase) should be logged and at which level (None, Metadata, Request, RequestResponse). Only when this flag is present does the kube-apiserver generate audit events; simultaneously configured backends like --audit-log-path or --audit-webhook-config-file become active and receive those events.

Go deeper

Related to this question