Auditing Azure Storage Access

Quick Answer

Auditing is about answering who did what and when, which is a different job from controlling who is allowed to do something in the first place, and that distinction is why several plausible-sounding options here are actually wrong. Storage Analytics logs exist specifically to record detailed information about every request made against a storage account, successful or failed, which is the raw material an audit needs: individual access events with enough detail to reconstruct activity after the fact. Azure Monitor diagnostic settings complement this by giving you a configurable pipeline to route those resource logs, including storage's audit-relevant logs, to a destination like Log Analytics, another storage account, or Event Hubs, so the detailed log data can actually be collected, retained, and analyzed rather than just generated and discarded. The wrong options all confuse auditing with adjacent but different concerns: RBAC role assignments determine who has permission to act, not who did act; Azure Policy enforces configuration compliance rules going forward rather than recording historical access; and Microsoft Defender for Cloud focuses on surfacing security alerts and threats, not on providing a detailed, queryable record of every access request. When a question asks specifically about auditing access to data in storage, look for features that generate and route detailed request-level logs, not features about permissions, policy enforcement, or threat alerting.