This chapter dives deep into Entra ID Audit Logs and Sign-In Logs, two critical monitoring capabilities for security operations in Azure. Understanding these logs is essential for the AZ-500 exam, as approximately 15-20% of questions in the 'Security Operations' domain (Objective 4.2) test your ability to analyze, configure, and troubleshoot these logs. You'll learn the structure, retention, diagnostic settings, and how to use them for threat detection and incident response.
Jump to a section
Think of Entra ID Audit Logs and Sign-In Logs as a hotel's security camera system. The audit logs are like the cameras that record every action by staff: when a cleaner enters a room, when a manager changes a reservation, or when a security guard unlocks a door. These recordings are stored for a set period and can be reviewed to investigate incidents, ensure compliance, or identify policy violations. Sign-in logs, on the other hand, are like the check-in desk logs that record every guest who enters the hotel, including their name, room number, time of entry, and whether they used a key card or were escorted. If a guest fails to enter (e.g., wrong key), that attempt is also logged. The hotel also monitors for suspicious patterns, like multiple failed entries from the same person, which triggers an alert to security. Just as the hotel's system has retention policies (e.g., 30 days for lobby cameras, 90 days for guest logs), Entra ID has configurable retention and diagnostic settings. Both logs are essential for security operations: audit logs show who did what, and sign-in logs show who tried to access what.
What Entra ID Audit Logs and Sign-In Logs Are
Entra ID (formerly Azure AD) provides two primary types of activity logs for security monitoring: - Audit Logs: Record all changes made to the tenant, including user management, group management, application changes, and policy modifications. Every create, update, delete, or assign operation is logged. - Sign-In Logs: Record every sign-in attempt, both successful and failed, including interactive and non-interactive sign-ins, service principal sign-ins, and managed identity sign-ins.
These logs are part of Azure Monitor and can be streamed to Log Analytics workspaces, Event Hubs, or storage accounts for long-term retention and advanced analysis.
Why They Exist
Security operations rely on these logs to:
Detect unauthorized access (e.g., brute force attempts, impossible travel)
Investigate incidents (e.g., who changed a critical policy)
Meet compliance requirements (e.g., GDPR, SOC 2)
Audit changes to Entra ID configuration
The AZ-500 exam tests your ability to configure diagnostic settings, interpret log entries, and use KQL queries to extract meaningful information.
How They Work Internally
Audit Logs: Every time an admin or application performs a write operation in Entra ID via the portal, Graph API, or PowerShell, the system generates an audit log entry. The entry includes: - Activity: The operation name (e.g., "Add user", "Update application") - Actor: Who performed the operation (user or service principal) - Target: The object that was modified (user, group, app) - Timestamp: UTC time of the operation - Status: Success or Failure - Additional Details: JSON with more context (e.g., old and new values)
Sign-In Logs: When a user attempts to sign in, the authentication pipeline logs the attempt. The entry includes: - User: User principal name (UPN) - Application: The app being accessed (e.g., Office 365, custom app) - Client IP: Source IP address - Authentication Requirement: MFA, passwordless, etc. - Result: Success, Failure (with reason), Interrupted (e.g., MFA challenge) - Risk Detail: If risk detection is enabled, risk level (low, medium, high) - Location: Approximate geographic location from IP - Device: Device ID and compliance status
Retention and Pricing
By default: - Audit Logs: Retained for 30 days for Azure AD Free tier, 30 days for P1, and 30 days for P2 (but P2 allows custom retention via diagnostic settings) - Sign-In Logs: Retained for 30 days for Free, 30 days for P1, and 30 days for P2 (again, custom retention via diagnostic settings)
To retain logs longer, you must configure diagnostic settings to send logs to: - Log Analytics workspace: Up to 2 years by default, configurable up to 730 days (2 years) per workspace - Azure Storage: Indefinite retention (pay per GB) - Event Hubs: Real-time streaming to SIEM
Important for exam: Free tier retains only 7 days of sign-in logs (not 30). P1 and P2 retain 30 days. Audit logs are 30 days for all tiers.
Diagnostic Settings Configuration
To send logs to a Log Analytics workspace, you use diagnostic settings in the Entra ID portal under "Monitoring" > "Diagnostic settings". You can select: - AuditLogs: All audit events - SignInLogs: All sign-in events - NonInteractiveUserSignInLogs: Service principal and managed identity sign-ins - ServicePrincipalSignInLogs: Service principal sign-ins - ManagedIdentitySignInLogs: Managed identity sign-ins - ProvisioningLogs: User provisioning events - ADFSSignInLogs: AD FS sign-ins (if federated) - RiskyUsers: Users flagged as risky - UserRiskEvents: Risk events for users - NetworkAccessTrafficLogs: Traffic logs for Entra ID Internet Access
You can send to multiple destinations simultaneously.
KQL Queries for Security Operations
Common queries on the exam:
Find failed sign-ins in last 24 hours:
SigninLogs
| where TimeGenerated > ago(1d)
| where ResultType !in ("0", "50125", "50140")
| project TimeGenerated, UserPrincipalName, AppDisplayName, IPAddress, ResultType, ResultDescriptionFind audit events for a specific user:
AuditLogs
| where TimeGenerated > ago(7d)
| where InitiatedBy.user.userPrincipalName == "admin@contoso.com"
| project TimeGenerated, Activity, TargetResources, ResultDetect impossible travel:
SigninLogs
| where TimeGenerated > ago(1d)
| summarize min(TimeGenerated), max(TimeGenerated), Locations = make_set(Location) by UserPrincipalName, IPAddress
| where array_length(Locations) > 1Integration with Azure Monitor and Microsoft Sentinel
Logs can be ingested into Microsoft Sentinel (cloud-native SIEM) for advanced detection and automation. Sentinel uses built-in analytics rules for:
Brute force attacks (multiple failed sign-ins)
Impossible travel (geographically impossible logins)
Anomalous token usage
Leaked credentials
The exam may ask how to enable these detections: configure diagnostic settings to send logs to a Log Analytics workspace that is connected to Sentinel.
Common Pitfalls
Logs are not real-time: There is a latency of up to 5 minutes for audit logs and up to 10 minutes for sign-in logs.
Sign-in logs for service principals: Must be explicitly enabled via diagnostic settings; they are not included by default.
Retention: Changing diagnostic settings does not affect already stored logs; retention is based on the workspace or storage configuration.
Free tier limitations: Only 7 days of sign-in logs; if you need longer, upgrade to P1/P2 or use diagnostic settings with storage.
Exam-Relevant Numbers
Default retention: 30 days (audit and sign-in) for P1/P2, 7 days for Free sign-in logs
Maximum Log Analytics retention: 730 days (2 years) per workspace
Diagnostic settings can stream to up to 5 destinations (but typically one Log Analytics workspace is enough)
Sign-in log types: Interactive, NonInteractive, ServicePrincipal, ManagedIdentity
Result types: 0 = Success, 50125 = MFA required, 50140 = Interrupted, 53003 = Blocked by CA
How It Interacts with Related Technologies
Conditional Access: Sign-in logs show if CA policies were applied and whether access was granted or blocked. Look for the "ConditionalAccessPolicies" column.
Identity Protection: Risk events are recorded in sign-in logs; risky users are in separate logs.
Privileged Identity Management (PIM): Audit logs record activation of roles.
Azure Policy: Audit logs record policy assignments and changes.
Microsoft Defender for Cloud: Integrates with sign-in logs for threat detection.
Understanding these interactions is key for the exam because questions often combine multiple services.
Configure Diagnostic Settings
Navigate to Entra ID > Monitoring > Diagnostic settings. Click 'Add diagnostic setting'. Give it a name, then select the log categories you need: AuditLogs, SignInLogs, NonInteractiveUserSignInLogs, etc. Choose a destination: Send to Log Analytics workspace (select existing workspace), Archive to storage account (select storage account), or Stream to event hub (select namespace). You can select multiple destinations. Click Save. This enables continuous streaming of logs. Note: Diagnostic settings are tenant-level, not per-user.
Query Sign-In Logs in Log Analytics
Open Log Analytics workspace > Logs. Write a KQL query to filter sign-in logs. For example: ```kusto SigninLogs | where TimeGenerated > ago(1h) | where ResultType == "0" | project UserPrincipalName, AppDisplayName, IPAddress, Location, TimeGenerated ``` Run the query. Review the results. For security, you can filter for failed sign-ins (ResultType != "0") or specific users. The query can be saved or used in alerts.
Analyze Audit Logs for Changes
In Log Analytics, query AuditLogs to see who made changes. Example: ```kusto AuditLogs | where TimeGenerated > ago(7d) | where Activity == "Add user" | project TimeGenerated, InitiatedBy.user.userPrincipalName, TargetResources[0].displayName, Result ``` This shows all user creation events. For role changes, filter Activity like "Add member to role" or "Update role". Audit logs are crucial for tracking privilege escalation.
Set Up Alerts for Suspicious Activity
In Log Analytics, create a new alert rule. Use a query like: ```kusto SigninLogs | where TimeGenerated > ago(5m) | where ResultType !in ("0", "50125", "50140") | summarize FailedCount = count() by UserPrincipalName, IPAddress | where FailedCount > 10 ``` Set the alert logic to trigger when result count > 0. Configure action group (email, SMS, webhook). This alerts on brute force attempts. The exam tests your ability to configure alerts on sign-in failures.
Export Logs for Long-Term Retention
To retain logs beyond 30 days, use diagnostic settings to archive to Azure Storage. In the diagnostic setting, select 'Archive to a storage account' and choose an existing storage account. Set the retention policy for each log category (e.g., 365 days). Alternatively, send to Log Analytics workspace with custom retention (up to 730 days). For indefinite retention, use storage account with lifecycle management policy. The exam may ask which option is cheapest or longest retention.
Enterprise Scenario 1: Incident Investigation after a Data Breach
A large financial institution suspects that a compromised admin account was used to exfiltrate data. The security team uses Entra ID Sign-In Logs to identify all sign-ins from that account in the last 90 days. They stream logs to a Log Analytics workspace with 2-year retention. Using KQL, they filter for sign-ins from unusual IP addresses (e.g., outside the corporate VPN) and correlate with audit logs to see what changes were made (e.g., adding a new user, modifying a role). They discover that the attacker created a new service principal with contributor rights and used it to access Azure Key Vault. The logs provide the exact timestamp, IP, and actions. The team then revokes the compromised account and implements conditional access policies to block sign-ins from untrusted locations. Common issues: logs not retained long enough (only 30 days by default), requiring proactive configuration. Performance: streaming to Log Analytics adds minimal latency (5-10 minutes). Cost: Log Analytics ingestion costs ~$2.30 per GB ingested; for a large tenant with millions of sign-ins, this can be significant.
Enterprise Scenario 2: Compliance Auditing for GDPR
A healthcare company must audit all user access to patient data. They enable audit logs for Entra ID and stream them to a Log Analytics workspace. They create a dashboard that shows all changes to user accounts and role assignments. They also set up alerts for any privileged role activation outside business hours. The compliance team runs monthly reports using KQL queries that export to Excel. Misconfiguration: if they forget to enable 'NonInteractiveUserSignInLogs', they miss service principal sign-ins that might be accessing data. Scale: with 50,000 users, they ingest about 10 GB of logs per month. They use Azure Storage archive for logs older than 1 year to save costs.
Enterprise Scenario 3: Detecting Brute Force Attacks
A retail company notices an increase in failed sign-ins. They configure diagnostic settings to send sign-in logs to a Log Analytics workspace and create an alert rule that triggers when any user has more than 10 failed sign-ins within 5 minutes. The alert sends an email to the security team. They also use Identity Protection to automatically block risky sign-ins. Common mistake: they initially set the threshold too low (e.g., 3 failures), causing false positives from legitimate users forgetting passwords. After tuning to 10 failures, they catch a real brute force attack from a botnet. The logs show the attacker's IP, which is then blocked via a network security group.
What the AZ-500 Exam Tests (Objective 4.2)
The exam focuses on:
Configuring diagnostic settings for Entra ID logs (which categories to enable, where to send)
Interpreting sign-in log entries (ResultType codes, risk levels, conditional access details)
Using KQL to query logs for security incidents (failed sign-ins, audit changes)
Retention policies and cost implications
Integration with Microsoft Sentinel and Identity Protection
Top 3-4 Wrong Answers Candidates Choose
1. Wrong: "Sign-in logs are retained for 90 days by default." Why chosen: Many think Azure AD P2 gives 90 days, but it's actually 30 days. The exam tests this exact number. Correct: 30 days for P1/P2, 7 days for Free.
2. Wrong: "To retain logs for more than 30 days, you must upgrade to Azure AD P2." Why chosen: Candidates confuse licensing with retention. Actually, you can retain logs longer by configuring diagnostic settings to send to Log Analytics or storage, even with Free tier (though Free tier has limited sign-in logs). The exam emphasizes that retention is a configuration, not a license feature.
3. Wrong: "Audit logs record all sign-in attempts." Why chosen: Confusion between audit and sign-in logs. Audit logs record changes to the directory, not sign-ins. Sign-in logs record authentication attempts. The exam will ask which log to use for a specific scenario.
4. Wrong: "You can view sign-in logs from the last 30 days without any configuration." Why chosen: While true for P1/P2, candidates forget that Free tier only has 7 days. The exam may present a scenario with Free tier.
Specific Numbers and Terms
ResultType 0 = Success
ResultType 50125 = MFA required
ResultType 50140 = Interrupted (e.g., user canceled)
ResultType 53003 = Blocked by Conditional Access
Risk levels: low, medium, high
Diagnostic setting categories: AuditLogs, SignInLogs, NonInteractiveUserSignInLogs, ServicePrincipalSignInLogs, ManagedIdentitySignInLogs
Maximum Log Analytics retention: 730 days
Free tier sign-in log retention: 7 days
Edge Cases the Exam Loves
Service principal sign-ins: They are not in the default SignInLogs; you must enable NonInteractiveUserSignInLogs or ServicePrincipalSignInLogs.
B2B guest users: Their sign-in logs appear in the resource tenant, not the home tenant.
When using diagnostic settings, you can send to multiple destinations, but each destination incurs separate costs.
If you delete a Log Analytics workspace, logs are lost. Always use a separate workspace for security logs.
How to Eliminate Wrong Answers
If a question asks about who performed an action, use AuditLogs (not SignInLogs).
If a question asks about failed sign-ins, use SignInLogs.
If a question asks about long-term retention, think diagnostic settings to storage or Log Analytics.
If a question mentions '30 days', check the tier: Free tier has 7 days for sign-in logs.
Always check if the scenario requires real-time streaming (Event Hubs) or historical analysis (Log Analytics).
Audit logs track configuration changes; sign-in logs track authentication attempts.
Default retention: 30 days for audit logs (all tiers); 7 days for sign-in logs (Free), 30 days (P1/P2).
To retain logs longer, configure diagnostic settings to send to Log Analytics (up to 730 days) or Azure Storage (indefinite).
Sign-in log ResultType 0 = Success, 50125 = MFA required, 50140 = Interrupted, 53003 = Blocked by CA.
Service principal and managed identity sign-ins require explicit diagnostic setting categories.
Use KQL to query logs for security incidents; common queries filter failed sign-ins or audit changes.
Diagnostic settings can stream to multiple destinations (Log Analytics, Storage, Event Hubs) simultaneously.
Free tier sign-in logs only show last 7 days; upgrade or use diagnostic settings for longer retention.
B2B guest sign-in logs appear in the resource tenant, not the home tenant.
Latency: audit logs up to 5 minutes, sign-in logs up to 10 minutes.
These come up on the exam all the time. Here's how to tell them apart.
Audit Logs
Records changes to Entra ID objects (users, groups, apps, policies).
Includes actor (who made the change) and target (what was changed).
Retained 30 days for all tiers (Free, P1, P2).
Used for compliance and configuration tracking.
Example: 'Update user' or 'Add member to role'.
Sign-In Logs
Records authentication attempts (success and failure).
Includes user, app, IP, location, device, risk level.
Retained 7 days for Free, 30 days for P1/P2.
Used for threat detection and access monitoring.
Example: 'User sign-in failed due to invalid password'.
Mistake
Audit logs and sign-in logs are the same thing.
Correct
Audit logs record configuration changes (e.g., user created, policy changed). Sign-in logs record authentication attempts. They serve different purposes and have different schemas.
Mistake
All sign-in logs are retained for 30 days by default regardless of license.
Correct
Free tier retains sign-in logs for only 7 days. Azure AD P1 and P2 retain for 30 days. Audit logs are 30 days for all tiers.
Mistake
You can increase retention beyond 30 days by upgrading to Azure AD P2.
Correct
Retention beyond 30 days is achieved by configuring diagnostic settings to send logs to Log Analytics (up to 730 days) or Azure Storage (indefinite). P2 does not automatically extend retention.
Mistake
Sign-in logs include all sign-ins from service principals and managed identities by default.
Correct
By default, only interactive user sign-ins are included. You must explicitly enable NonInteractiveUserSignInLogs, ServicePrincipalSignInLogs, and ManagedIdentitySignInLogs in diagnostic settings.
Mistake
You can view sign-in logs from the Azure portal for more than 30 days if you have P2.
Correct
The portal only shows logs up to the retention period (30 days). To view older logs, you must query the Log Analytics workspace or storage account where they were exported.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Audit logs record changes made to the Entra ID directory, such as creating a user, updating a group, or modifying a policy. They include who performed the action and what was changed. Sign-in logs record every authentication attempt, whether successful or failed, including details like user, application, IP address, and risk level. Use audit logs for compliance and configuration tracking; use sign-in logs for detecting unauthorized access attempts.
For Azure AD Free tier, sign-in logs are retained for 7 days. For Azure AD Premium P1 and P2, they are retained for 30 days. Audit logs are retained for 30 days regardless of tier. To retain logs longer, you must configure diagnostic settings to export them to a Log Analytics workspace (up to 730 days) or Azure Storage (indefinite).
Go to Entra ID > Monitoring > Diagnostic settings. Click 'Add diagnostic setting', give it a name, select the log categories (e.g., AuditLogs, SignInLogs), choose 'Send to Log Analytics workspace', and select an existing workspace. Click Save. Logs will start streaming to the workspace within minutes. You can then query them using KQL.
ResultType 50125 indicates that the sign-in was interrupted because multi-factor authentication (MFA) was required. This typically happens when a conditional access policy requires MFA. The sign-in may succeed after the user completes MFA. Other common codes: 0 = Success, 50140 = Interrupted (user canceled), 53003 = Blocked by Conditional Access.
Yes, but they are not included in the default SignInLogs category. You must enable the 'ServicePrincipalSignInLogs' or 'NonInteractiveUserSignInLogs' category in diagnostic settings. Once enabled, these logs are sent to your chosen destination (Log Analytics, Storage, Event Hubs).
The maximum retention period for a Log Analytics workspace is 730 days (2 years) by default. You can configure retention per table (e.g., SigninLogs, AuditLogs) in the workspace settings. For longer retention, archive logs to Azure Storage with lifecycle management.
Query sign-in logs for multiple failed attempts from the same user or IP within a short time. Example KQL: ```kusto SigninLogs | where TimeGenerated > ago(5m) | where ResultType != "0" | summarize FailedCount = count() by UserPrincipalName, IPAddress | where FailedCount > 10 ``` Set up an alert rule in Log Analytics to notify when this query returns results.
You've just covered Entra ID Audit Logs and Sign-In Logs — now see how well it sticks with free AZ-500 practice questions. Full explanations included, no account needed.
Done with this chapter?