CKS Practice Question: Which kubectl command can be used to view the…

Answer analysis

Option-by-option breakdown

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

• ✗

  kubectl logs -n kube-system kube-apiserver-<node> | grep audit

  Why it's wrong here

  The kube-apiserver logs contain entries for individual requests and events, but they do not expose the process's command-line arguments or mounted configuration files. Even if the audit backend is enabled, the log lines will show audit log entries (e.g., audit IDs, response statuses) rather than the audit-policy-file path. Searching for 'audit' might match many unrelated lines, and the flag is only visible in the static pod manifest, not in stdout/stderr. This command is therefore unreliable and cannot substitute for inspecting the pod's YAML definition.

• ✗

  kubectl describe clusterrolebinding audit

  Why it's wrong here

  There is no default ClusterRoleBinding named 'audit', and audit policies are not represented as RBAC objects in the Kubernetes API. AuditPolicy configuration is a standalone YAML file referenced by the --audit-policy-file flag on the API server; it is not a ClusterRole or ClusterRoleBinding resource. Running `kubectl describe clusterrolebinding audit` would fail with a NotFound error because such a resource does not exist. Even if you created one manually, it would have no connection to the audit policy path, making this command fundamentally incorrect for viewing the policy.

• ✓

  kubectl get -n kube-system pods kube-apiserver-<node> -o yaml | grep audit-policy-file

  Why this is correct

  This command is correct because it retrieves the complete JSON/YAML specification of the kube-apiserver static pod from the cluster's API. Inside that output, the container's command array contains the --audit-policy-file flag, and the volume mounts section shows the corresponding hostPath mapping, such as /etc/kubernetes/audit-policy.yaml. By grepping for 'audit-policy-file', you directly extract the exact path to the audit policy file. This is the standard, non-intrusive way to verify which audit policy the API server is using, since static pod specs are automatically reflected in the pod object.

• ✗

  kubectl get auditpolicy

  Why it's wrong here

  AuditPolicy is not a recognized Kubernetes API resource type, so `kubectl get auditpolicy` will return an error such as 'the server doesn't have a resource type "auditpolicy"'. Audit policies are not CRDs, built-in objects, or stored in etcd as Kubernetes resources; they are plain YAML files on the control plane node's filesystem. The API server loads the policy file at startup via the --audit-policy-file flag. To view the active audit policy, you must inspect the API server pod definition or access the file directly on the node—not call `kubectl get` on a nonexistent resource type.

Go deeper

Related to this question