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.

• ✗

  --feature-gates=Auditing=true

  Why it's wrong here

  --feature-gates=Auditing=true is not the correct way to enable auditing because auditing was stabilized in the Kubernetes API server and is not exposed as a feature gate. Feature gates are used to enable alpha or beta functionality during the transition period, but the Auditing feature gate has been removed in modern releases (the gate became GA and was removed). Even if this flag were accepted, it only toggles the feature on; without a defined audit policy file, the API server has no rules specifying which events to log and at what detail, so audit records would still not be produced. Therefore, this flag neither activates the audit backend nor supplies the necessary configuration to capture events.

• ✗

  --audit-log-path=/var/log/audit.log

  Why it's wrong here

  Using --audit-log-path=/var/log/audit.log alone does not enable audit logging because it merely tells the API server where to write audit logs. According to Kubernetes documentation, if no audit policy file is provided via --audit-policy-file, the audit log backend is disabled entirely, meaning even though the path is configured, no audit events will be written. Additionally, the log path is just the output destination; it lacks the crucial rule definitions that determine which requests are logged and at what verbosity. Thus, specifying only this flag leaves you with a defined sink but no source of data, so it is nowhere near sufficient to enable auditing.

• ✓

  --audit-policy-file=/etc/kubernetes/audit-policy.yaml

  Why this is correct

  Audit logging levels are defined inside an audit policy YAML, and the kube-apiserver only emits audit events when started with --audit-policy-file pointing at that file. The policy's rules set the Metadata level for the relevant request stages, so this flag is the mechanism that enables the required logging.

• ✗

  --audit-log-maxsize=100

  Why it's wrong here

  Setting --audit-log-maxsize=100 is a rotation parameter that controls the maximum size in megabytes of the audit log file before it is rotated, but it does not enable or activate audit logging at all. This flag only takes effect when an audit backend, specifically a log file backend, is already operational; otherwise, the API server ignores it because there is no active audit stream to rotate. In a standard kube-apiserver configuration, this works together with --audit-log-path and, more importantly, requires a valid --audit-policy-file first. Since the policy is absent, this setting cannot turn on auditing and is merely a tuning knob for an already-configured logging system.

Go deeper

Related to this question