After a kubeconfig leak, nobody can determine who deleted the lock-gate deployment on AKS. What should the security engineer configure for API-server accountability?
Select an answer to reveal the explanation.
Short Explanation
After a leaked kubeconfig, you need the API server’s paper trail. Pipe AKS control-plane and Kubernetes audit logs into Log Analytics via diagnostic settings—then you can see who deleted the lock-gate deployment.
Full Explanation
API-server accountability after a kubeconfig leak requires shipping AKS control-plane and Kubernetes audit logs to a Log Analytics workspace through diagnostic settings. Those categories record who called the API to delete the lock-gate deployment; without them, security cannot reconstruct the action even if the leak is later contained.
Authoring production Sentinel rules and workbooks first, then deciding later whether audit logs are needed, fails by concept: analytics without the underlying audit/control-plane logs have nothing authoritative to query. Enabling only container stdout on nodes and skipping Kubernetes audit categories fails because application logs do not reliably capture API delete events performed with a stolen kubeconfig. Storing kubeconfigs in a shared storage account with soft delete addresses credential file recovery, not API-server accountability for what the stolen credential already did.
Exam caveat: enable the right diagnostic categories (kube-audit / control plane) to Log Analytics—not only kubelet or container console logs. Operational check: confirm diagnostic settings on the AKS resource target a workspace, generate a benign API change, and verify a corresponding audit entry is queryable before the next incident.