Diagnostic logs in Data Lake Analytics should be enabled

What does the recommendation "Diagnostic logs in Data Lake Analytics should be enabled" check?

Audits each Data Lake Analytics account for at least one diagnostic setting that ships the resource logs (the Audit and Requests categories) to a durable destination: a Log Analytics workspace, a storage account or an Event Hub. It only confirms that a setting exists and routes those categories somewhere. It does not read the log contents, does not verify a sensible retention period, does not check that anyone is querying or alerting on the data, and does not cover the Azure activity log, which is recorded separately at the subscription level regardless of this control. The recommendation is audit-only: the underlying policy uses the AuditIfNotExists effect, so it reports non-compliant accounts but never changes them for you. Note that Azure Data Lake Analytics reached end of life on 29 February 2024, so for live workloads this guidance maps to its successors, Azure Synapse Analytics or Microsoft Fabric.

Why does "Diagnostic logs in Data Lake Analytics should be enabled" matter?

Without a diagnostic setting, the per-job Audit and Requests logs only live inside the account and age out, so the moment you need to reconstruct who submitted which U-SQL job or which API call touched your data, the evidence is already gone. That gap surfaces at the worst possible time: during an incident investigation, a customer breach notification or an auditor's request for an activity trail you cannot produce. Routing the logs to durable storage or a workspace gives you a tamper-resistant record you can query months later and build detections on, which is the whole point of the LT-3 logging control. Because the policy is audit-only, the recommendation flagging means the account is genuinely unmonitored today, not merely awaiting an automated fix.

How do I fix "Diagnostic logs in Data Lake Analytics should be enabled"?

1. Create a diagnostic setting on the account that forwards the Audit and Requests log categories to a Log Analytics workspace: az monitor diagnostic-settings create --name dla-logs --resource <account-resource-id> --workspace <workspace-resource-id> --logs '[{"category":"Audit","enabled":true},{"category":"Requests","enabled":true}]'.
2. Enforce it at scale by assigning the built-in audit policy rather than hardcoding its GUID. Look the definition up by display name, then assign it: pid=$(az policy definition list --query "[?displayName=='Diagnostic logs in Data Lake Analytics should be enabled'].name" -o tsv); az policy assignment create --name dla-diag-logs --policy "$pid" --scope /subscriptions/<sub-id>.
3. Bake the setting into Bicep so new accounts inherit it: a Microsoft.Insights/diagnosticSettings resource scoped to the account, with workspaceId set and a logs array enabling the Audit and Requests categories.

# Turn on the security-relevant App Service logs and send them to a workspace.
WS=$(az monitor log-analytics workspace show \
  -g central-logging -n estate-logs --query id -o tsv)

for id in $(az webapp list --query "[].id" -o tsv); do
  has=$(az monitor diagnostic-settings list --resource "$id" \
        --query "length(value)" -o tsv)
  if [ "$has" = "0" ]; then
    az monitor diagnostic-settings create \
      --name to-log-analytics \
      --resource "$id" \
      --workspace "$WS" \
      --logs '[{"category":"AppServiceHTTPLogs","enabled":true},
               {"category":"AppServiceAuditLogs","enabled":true},
               {"category":"AppServiceConsoleLogs","enabled":true}]'
    echo "$(basename "$id"): diagnostic logging enabled to estate-logs"
  fi
done

# Ratchet it shut: built-in policy adds the setting to any new App Service.
az policy assignment create \
  --name deploy-appservice-diag \
  --policy 0c6cd767-1a1d-484b-a897-68e398c03aeb \
  --location uksouth \
  --mi-system-assigned \
  --scope "/subscriptions/00000000-0000-0000-0000-000000000000"