A logging solution is the foundation of operational visibility, security investigation, and compliance evidence. The architect must decide what to capture, where to land it, who can read it, and how long to keep it, against requirements drawn from operations, security, audit, and finance. The wrong sink choice forces expensive re-ingestion; the wrong retention setting either inflates cost or fails the auditor; the wrong access model exposes sensitive payloads to teams that should not see them.
Azure separates log data into three families: platform logs (Activity log entries for control-plane actions, Microsoft Entra ID audit and sign-in logs, and per-resource diagnostic logs), application telemetry (instrumented via Application Insights for traces, requests, dependencies, exceptions, and custom events), and infrastructure or guest-OS logs (collected by the Azure Monitor Agent from Windows event channels, syslog, and performance counters). Each family has a distinct collection model, but all three can land in the same destination: a Log Analytics workspace built on Azure Data Explorer storage and queried with Kusto Query Language.
The default recommendation for Azure-native workloads is one or more Log Analytics workspaces attached to a Microsoft Sentinel solution where security analytics are required. The workspace is the smallest unit of access control and the smallest unit of data plan selection. Two pricing dimensions matter: the commitment tier (Pay-As-You-Go versus Commitment Tiers in 100 GB/day steps up to 5,000 GB/day) and the table plan, which is set per table. The Analytics plan supports the full KQL surface and alerting; the Basic plan supports where, project, extend, parse, and summarize count with a reduced ingestion price; the Auxiliary plan is even cheaper but supports a narrower query surface and is intended for low-frequency archives. Plan selection per table lets the architect keep SecurityEvent on Analytics for real-time hunting while moving ContainerLogV2 or AppTraces chatter to Basic.
Retention in Log Analytics is split into interactive retention (queryable for hot investigation, between 4 and 730 days) and long-term retention (archive tier, queryable via search jobs or restore, up to 12 years). Per-table interactive retention overrides the workspace default, which lets the architect store firewall logs for 30 days but Microsoft Entra ID sign-ins for 180 days within one workspace. When retention exceeds 730 days, the data sits in low-cost archive and surfaces only when a search job is launched.
The second sink option is Azure Storage, used for compliance-driven immutable long-term retention. Storage is cheap but not searchable; recovery means rehydrating into a workspace or pulling files with AzCopy. Storage is the right destination when the requirement reads "retain 7 years for regulatory audit, no routine query" or when an external SIEM is the read path and Azure is only the durable copy.
The third sink option is Azure Event Hubs, used to stream logs to a partner SIEM (Splunk, IBM QRadar, ArcSight, Sumo Logic) or to a custom downstream processor. Event Hubs adds streaming throughput in Throughput Units or Processing Units, partition design, and a 7-day default retention; the architect sizes partitions to the consumer parallelism the SIEM connector supports.
💡 Exam Trap: A workspace cannot be moved across regions. Pick the region with care because regional residency for log data follows the workspace, not the resource being logged. A virtual machine in West Europe sending logs to a workspace in East US stores those logs in East US, which can violate a data residency clause.
📊 Limit: Log Analytics commitment tiers begin at 100 GB/day and step in increments of 100 GB/day up to 500 GB/day, then in 1,000 GB/day steps up to 5,000 GB/day. Per-workspace daily caps protect against runaway ingestion. Interactive retention spans 4 to 730 days per table; archive extends total retention to 12 years.
resource workspace 'Microsoft.OperationalInsights/workspaces@2023-09-01' = {
name: 'log-shared-prod-weu'
location: 'westeurope'
properties: {
sku: {
name: 'CapacityReservation'
capacityReservationLevel: 500
}
retentionInDays: 90
workspaceCapping: {
dailyQuotaGb: 600
}
features: {
enableLogAccessUsingOnlyResourcePermissions: true
}
}
}
resource basicTablePlan 'Microsoft.OperationalInsights/workspaces/tables@2023-09-01' = {
parent: workspace
name: 'AppTraces'
properties: {
plan: 'Basic'
retentionInDays: 30
totalRetentionInDays: 1095
}
}
The enableLogAccessUsingOnlyResourcePermissions flag is the resource-context access mode. When set, a user with Reader on a virtual machine can run KQL only against rows whose _ResourceId matches that VM, even if they cannot read the workspace itself. The alternative workspace-context mode grants whole-workspace visibility to anyone with workspace read. Resource-context is the right default for multi-team shared workspaces; workspace-context fits a dedicated SecOps workspace.
Sub-topic: Recommend a solution to allow applications to access Azure resources
Logging requires the application or workload identity to be authorized against the workspace, against the storage account holding archived blobs, and against the secret store holding any HTTP collection credentials. The application access pattern the architect should recommend by default is a managed identity. A managed identity is a service principal inside Microsoft Entra ID whose credentials are managed by the platform and never surfaced to the workload or the developer.
There are two shapes. A system-assigned managed identity is bound to the lifecycle of a single Azure resource (VM, App Service, Function, Container App, AKS pod via workload identity, Logic App, Data Factory). When the resource is deleted, the identity is deleted with it. A user-assigned managed identity is a standalone resource that one or more workloads attach to. User-assigned is the recommendation when several resources share a single permission grant (for example, a fleet of App Services that all read the same Key Vault), when blue-green deployments must hold the same identity across resource recreation, or when the identity must outlive any single workload.
Federated identity credentials extend the same model to workloads that run outside Azure. A GitHub Actions workflow, a GitLab pipeline, a Kubernetes workload on EKS, or an OpenID Connect-capable system can exchange its native token for a Microsoft Entra ID token without storing a client secret. The architect configures a federated credential on a user-assigned managed identity (or on an app registration) that trusts a specific issuer, subject, and audience.
# Create a user-assigned managed identity
az identity create \
--name id-app-logging-prod \
--resource-group rg-identity-prod \
--location westeurope
# Grant it Log Analytics Contributor on the workspace
az role assignment create \
--assignee-object-id $(az identity show -n id-app-logging-prod -g rg-identity-prod --query principalId -o tsv) \
--assignee-principal-type ServicePrincipal \
--role "Log Analytics Contributor" \
--scope $(az monitor log-analytics workspace show -n log-shared-prod-weu -g rg-monitor-prod --query id -o tsv)
# Attach the identity to an App Service
az webapp identity assign \
--name app-orderapi-prod \
--resource-group rg-app-prod \
--identities $(az identity show -n id-app-logging-prod -g rg-identity-prod --query id -o tsv)
⚠️ Anti-Pattern: Storing an Application Insights instrumentation key or connection string in an App Settings entry as plain text and treating that as the access model. The connection string permits telemetry write but does not gate read. Worse, rotating the workspace ingestion key forces a redeploy of every workload. Use managed identity authentication for Application Insights (set
APPLICATIONINSIGHTS_AUTHENTICATION_STRINGto a Microsoft Entra ID credential) so ingestion is gated by RBAC, not a shared string.
💡 Exam Trap: A system-assigned managed identity vanishes when its host resource is deleted, taking every role assignment that referenced its object ID with it. A user-assigned identity does not, which is why blue-green or canary deployments that recreate resources must use user-assigned. Picking system-assigned for an App Service that is rebuilt monthly produces a permission loss every cycle.
Decision Anchor: Choose a system-assigned managed identity when the workload is a single, long-lived Azure resource and the identity should die with it. Choose a user-assigned managed identity when several resources share a permission set, when deployments recreate the workload, when the identity is consumed by AKS pods through workload identity federation, or when the identity must trust an external OIDC issuer through a federated credential. Choose a service principal with a client secret or certificate only when neither managed-identity option is supported by the workload.
🎯 Scenario: A multi-region App Service plan hosts an order API. Telemetry must ingest into a single Log Analytics workspace in West Europe; the application also reads connection strings from Azure Key Vault. Operations rebuilds the App Service every release through Bicep. The architect recommends one user-assigned managed identity (
id-app-orderapi) attached to each App Service in each region. Role assignments grant Monitoring Metrics Publisher on the Application Insights component and Key Vault Secrets User on the Key Vault. Because the identity is decoupled from the App Service lifecycle, the redeploy keeps both permissions intact, and the App Settings file holds only the workspace connection string with no key material.