AZ-500 Practice Question: Secure Azure using Microsoft Defender for Cloud and Microsoft Sentinel

Answer analysis

Option-by-option breakdown

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

• ✓

  Configure data retention for the specific tables that need long-term retention

  Why this is correct

  Configuring table-level retention in Log Analytics is the most precise way to meet long-term retention requirements because each table (e.g., SecurityEvent, SigninLogs) can have its own retention period, independent of the workspace default. This allows you to keep security-critical tables for up to 730 days (or 2 years for some data types) while avoiding the cost of retaining verbose, low-value tables like Perf or Heartbeat for that long. The Azure portal, Azure CLI, and the Tables API all support setting per-table retention, making it a supported and audit-friendly solution.

• ✗

  Change the workspace retention setting to 730 days

  Why it's wrong here

  Changing the workspace's retention setting to 730 days applies a single, uniform retention period to every table in the workspace. While this does ensure long-term availability, it is overkill and unnecessarily expensive because you pay for two years of storage on all tables, including those that are ephemeral, noisy, or not needed for compliance. It also lacks granularity: if a specific table needs 90 days and another needs 730, workspace-level retention cannot accommodate that. This blunt approach doesn't account for varying data lifecycles across log types, which is why table-level configuration is preferred.

• ✗

  Use Azure Policy to enforce retention on the Log Analytics workspace

  Why it's wrong here

  Azure Policy can only audit and enforce compliance by checking whether a Log Analytics workspace or table has a retention period set to a required value; it cannot directly modify the retention property on the workspace. Built-in regulatory compliance policies like 'Log Analytics workspaces should have retention periods of at least X days' are evaluation-only and will flag non-compliant resources, but the actual change must be made manually or via ARM/Bicep templates. Even a 'DeployIfNotExists' policy would require a built-in template to apply a retention setting, which is not currently available for this scenario. Thus, Policy is a governance tool, not a mechanism to configure retention.

• ✗

  Export logs to an Azure Storage account and set a lifecycle management policy

  Why it's wrong here

  Exporting logs to an Azure Storage account and applying a lifecycle management policy is a long-term archival strategy, but it does not change or override the Log Analytics workspace retention setting. The exported data is a separate copy, and the original logs remain in the workspace until their configured retention period expires, so you still incur Log Analytics storage costs until then. Furthermore, exported logs in Azure Storage cannot be directly queried by Sentinel, so you lose the ability to perform security investigations on that data. Lifecycle management in storage governs blob tiering and deletion, not Log Analytics retention, making this an incomplete substitute for a retention configuration.

Go deeper

Related to this question