Study guide
15.3 Interpreting the Activity Log
Microsoft 365 Administrator Expert MS-102
Track your progress as you read
Finished sections get a check mark.
1 Introduction & Exam Overview
1.1 MS-102 Exam Facts & Blueprint 1.2 Registration, Retake & Renewal 1.3 Study Strategy & Using This Guide
2 Tenant Setup, Domains & Org Settings
2.1 Creating a Microsoft 365 Tenant 2.2 Implementing and Managing Domains 2.3 Configuring Org Settings: Security, Privacy & Profile
3 Service Health, Network & Software Updates
3.1 Monitoring Service Health & Notifications 3.2 Network Connectivity Insights 3.3 Configuring & Monitoring Software Updates
4 Adoption, Usage & Microsoft 365 Backup
4.1 Monitoring Adoption & Usage 4.2 Configuring & Managing Microsoft 365 Backup
5 Users, Contacts, Groups & Shared Mailboxes
5.1 Creating & Managing Users Including External Users 5.2 Creating & Managing Contacts 5.3 Managing Microsoft 365 Groups & Shared Mailboxes
6 Licensing & Bulk User Management
6.1 Managing & Monitoring Microsoft 365 Licenses 6.2 Bulk User Management with Graph & Entra PowerShell
7 Roles, Admin Units & Privileged Identity Management
7.1 Implementing & Managing Roles in M365 & Entra ID 7.2 Managing Permissions for Defender XDR, Purview & Workloads 7.3 Managing Delegation with Administrative Units 7.4 Managing Entra ID Roles in PIM
8 Identity Synchronization with Entra Connect
8.1 Preparing for Identity Synchronization & IdFix 8.2 Directory Sync with Entra Connect Sync & Cloud Sync 8.3 Monitoring Sync with Entra Connect Health 8.4 Troubleshooting Synchronization
9 Authentication, SSPR & Password Protection
9.1 Implementing & Managing Authentication Methods 9.2 Self-Service Password Reset (SSPR) 9.3 Microsoft Entra Password Protection 9.4 Investigating & Resolving Authentication Issues
10 Identity Protection, Conditional Access & MFA
10.1 Planning for Identity Protection 10.2 Implementing Entra Identity Protection 10.3 Planning & Implementing Conditional Access Policies 10.4 Managing MFA with Conditional Access
11 Defender XDR Posture, Incidents & Threat Intelligence
11.1 Security Exposure Management & Secure Score 11.2 Incidents, Alerts & Advanced Hunting 11.3 Reviewing Defender XDR Reports 11.4 Defender Threat Intelligence
12 Defender for Office 365: Policies, Alerts & Investigation
12.1 Threat Policies & Rules in Defender for Office 365 12.2 Configuring Alert Policies 12.3 Investigating & Responding to Email Threats
13 Attack Simulation & Restricted Entities
13.1 Managing Attack Simulations & Training 13.2 Managing Restricted Entities & Blocked Users
14 Defender for Endpoint
14.1 Onboarding Devices to Defender for Endpoint 14.2 Configuring Endpoint Settings 14.3 Defender Vulnerability Management Dashboard
15 Defender for Cloud Apps
15.1 Configuring the App Connector for Microsoft 365 15.2 Defender for Cloud Apps Policies & Alerts 15.3 Interpreting the Activity Log 15.4 Cloud App Discovery
16 Purview Information Protection & Data Lifecycle
16.1 Sensitive Information Types 16.2 Retention Labels & Policies 16.3 Sensitivity Labels & Policies 16.4 Monitoring Label Usage: Content & Activity Explorer
17 Purview Data Loss Prevention
17.1 DLP Policies for Microsoft 365 Workloads 17.2 Configuring Endpoint DLP 17.3 Reviewing & Responding to DLP Alerts, Events & Reports
18 Final Review & Exam Strategy
18.1 Exam-Day Strategy & Question Handling 18.2 Final Review Checklist & Next Steps
15.3 Interpreting the Activity Log
Key Takeaways Explain This Topic AI
The Defender for Cloud Apps Activity log is the unified record store of in-app actions across connected apps, pulled via app connector APIs plus Microsoft Graph audit (Exchange, SharePoint, OneDrive, Teams) and Microsoft Entra ID sign-in/audit events; each record carries actor, activity type, app, IP address, location, device, and result
Every source IP is enriched with built-in IP tags (Anonymous proxy, Botnet, Tor) and an IP category (Corporate, Administrative, Risky, VPN, Cloud provider); custom corporate ranges override built-in tags and suppress impossible-travel false positives from VPN egress and branch offices
Three policy families consume activity: user-authored Activity policies, built-in non-deletable Anomaly detection policies (UEBA/ML, e.g. impossible travel, suspicious inbox forwarding, ransomware activity), and real-time Session policies enforced through Conditional Access App Control rather than post-hoc on the Activity log
From any activity you can apply a governance action (require user to sign in again, suspend user, quarantine file, ban OAuth app, create policy from activity); remediation is recorded in the separate Governance log, not the Activity log
Defender for Cloud Apps retains Activity log data for about 180 days; Purview Audit (Standard) keeps 180 days, Audit (Premium) keeps 1 year for key workloads with an optional 10-year add-on; for longer history, continuously export to Microsoft Sentinel or a Log Analytics workspace
Last updated: August 2026
What the Activity Log Contains
The Activity log in Microsoft Defender for Cloud Apps is the unified record store of every action users and apps take across your connected cloud apps. Each row is a single activity pulled by an app connector's API. For the Microsoft 365 connector , activities come from Microsoft Graph audit logs (Exchange, SharePoint, OneDrive, Teams) plus Microsoft Entra ID sign-in and audit events. For other connected apps (Salesforce, Google Workspace, AWS, Box), activities come from that provider's audit API. The same activity data is also surfaced for advanced hunting through the CloudAppEvents table in Microsoft Defender XDR and Microsoft Sentinel.
Each activity record exposes the following fields:
Actor — the user (or app/service principal) that performed the action, resolved to a Microsoft Entra ID user object when possible, with domain and organizational unit
Activity type — logon, file download, file share, admin role change, OAuth app grant, mailbox rule creation, and so on; an actionType distinguishes admin events from regular events
- App — the connected app and instance where the activity occurred
- IP address — source IP, enriched with reverse DNS, ISP, and IP tags
- Location — country/region and city derived from IP geolocation
Device — device identifier, device type, OS platform, management state (managed / unmanaged / compliant), and device tag
Result — success, failure, or timeout, with failure reason where available; an activity.takenAction field records whether the activity was blocked, proxied, encrypted, verified, or protected by a session policy
IP Tags and Why They Matter
Every source IP in the Activity log is classified with an IP category and one or more IP tags . The built-in IP categories are:
Corporate — public IPs of your internal network, branch offices, and Wi-Fi roaming ranges that you define in Settings → IP address ranges
- Administrative — IPs used by admins
- VPN — IPs for remote workers
- Cloud provider — IPs owned by cloud providers
Risky — IPs you consider risky; this category automatically includes IPs tagged as Anonymous proxy , Botnet , or Tor
Other — anything not classified
Built-in IP tags, derived from Microsoft threat intelligence, include Anonymous proxy , Botnet , and Tor exit nodes , plus tags for malware command-and-control servers, darknet scanning IPs, satellite providers, and Zscaler. Custom IP tags take precedence over built-in tags — for example, if a VPN egress IP is tagged Risky by threat intelligence but you define it as Corporate, the custom Corporate category wins.
Tagging VPN egress and branch-office ranges as Corporate is the single most effective way to suppress impossible-travel false positives, because the impossible-travel anomaly detection compares sign-in geos and ignores activity from corporate-tagged IPs when scoring travel distance.
Filtering and Investigating
The Activity log supports rich filtering. Typical filters include User (a specific user or group), App , IP address / IP tag / IP category , Location (country or region), Activity type , Action type , Device (managed vs. unmanaged, device tag), User agent , and Time range . When querying the full 6-month history, the portal restricts you to a subset of fields: Activity ID, Activity type, Action type, Application, IP address, Location, and User name.
Common Investigative Patterns
When you receive an alert or a tip about a potentially compromised account, the Activity log is the first place to look. Patterns worth searching for:
Admin privilege changes — a user added to Global Administrator or other privileged roles, especially outside business hours
Mass downloads — a single user downloading many files in a short window, a precursor to data exfiltration
Logons from risky locations — sign-ins from countries where the user has never signed in, or from anonymous proxy or Tor IPs
- OAuth app grants — the user consented to a third-party OAuth app, possibly a consent-phishing attack
- Inbox rule creation — a new mailbox rule that forwards mail externally or moves messages to a hidden folder
Impossible travel — two sign-ins from geographically distant locations within a time window shorter than physically possible
Opening an Activity for Governance
From any activity row you can open the activity drawer and apply a governance action . Activity-level governance actions include:
Require user to sign in again — revokes all refresh tokens and session cookies, forcing the user to re-authenticate to every app
Suspend user — sets the user to no access in the connected app; if logged in, they are immediately locked out
Confirm user compromised — sets the user's Entra ID risk level to high, triggering Identity Protection remediation
Revoke admin privileges — removes privileged roles from the account
File-level governance actions include quarantine (user quarantine or admin quarantine), trash , remove external sharing , make private , and apply or remove a Microsoft Purview sensitivity label . For OAuth grant activities, you can ban the OAuth app (revokes existing permissions and blocks future consent) or revoke the app (one-time revocation without blocking future consent).
Governance actions you apply — whether manual or automatic — are recorded in the separate Governance log (Settings → Governance log), which tracks success or failure of each remediation task and lets you retry or revert certain actions. The Activity log records what the user did; the Governance log records what Defender for Cloud Apps did in response.
The Three Policy Families That Consume Activity
Three policy families consume activity in Defender for Cloud Apps, and MS-102 questions test the distinction:
Activity policies are rules you author that match specific activities in the Activity log — for example, flag any OAuth grant requesting high-privileged scopes, or alert on admin activity from a non-corporate IP. You define filters, severity, and governance actions.
Anomaly detection policies are built-in, ML-driven detections using User and Entity Behavior Analytics (UEBA) . They baseline normal behavior for each user and tenant, then flag deviations across more than 30 risk indicators grouped into risk factors such as risky IP address, login failures, admin activity, inactive accounts, location, impossible travel, device and user agent, and activity rate. Built-in detections include impossible travel , activity from a TOR IP address , anonymous proxy activity , ransomware activity (renamed "Ransomware payment instruction file uploaded to {Application}"), suspicious inbox forwarding , and activity by a deprovisioned user . These policies are enabled by default after a 7-day learning period, can be scoped to users/groups and tuned with a sensitivity slider, but cannot be deleted — only disabled or tuned. Since June 2025, many have been migrated to a dynamic threat detection model that auto-adapts to the threat landscape.
Session policies act in real time through Conditional Access App Control , a reverse proxy that sits in front of the cloud app session. They can block activities (print, clipboard, download), protect downloads with sensitivity labels, or require step-up authentication. Session policies do not evaluate the Activity log post-hoc; they enforce controls inline, though session events are written back to the Activity log for audit.
Worked Triage: Alert to Governance Action
An impossible travel anomaly alert fires for a user who signed in from New York and, 20 minutes later, from an anonymous proxy abroad. You open the alert, then pivot into the Activity log pre-filtered to that user. You see the suspicious sign-in, a mass download of 240 files from SharePoint, and an OAuth grant to an unverified app requesting Mail.ReadWrite . From the sign-in row you apply require user to sign in again ; from the OAuth grant you ban the app ; from each downloaded file you quarantine to admin quarantine . Each action appears in the Governance log with a success status, and the user's session is terminated before exfiltration completes.
Activity Log vs Cloud Discovery vs Alerts Queue
These three views are frequently confused on the exam:
View What it contains Source Role
Activity log In-app actions across connected apps App connector APIs + Graph audit + Entra ID sign-in/audit Raw record store — input to activity and anomaly detection policies
Cloud Discovery reports Discovered apps and their traffic/users Firewall, proxy, and Defender for Endpoint logs Shows which unsanctioned apps users accessed from your network, not in-app activities
Alerts queue Policy-triggered notifications Output of activity, anomaly detection, file, OAuth, and discovery policies Output of policies; pivot to the Activity log to see the underlying timeline
In other words, the Activity log is the input to policies; the Alerts queue is the output . When you triage an alert, you pivot to the Activity log to see the full timeline of the user's actions.
Activity Log vs Microsoft Purview Audit
A common point of confusion: Defender for Cloud Apps surfaces Microsoft 365 audit events in its own Activity log, but the authoritative audit store for Microsoft 365 is Microsoft Purview Audit (Unified Audit Log) . Defender for Cloud Apps pulls a subset of those events through Microsoft Graph and enriches them with IP tags, geo, device context, and cross-app correlation. For a full legal-grade audit export, use Purview Audit; for behavioral investigation and policy enforcement across cloud apps, use the Defender for Cloud Apps Activity log.
Retention differs significantly:
Defender for Cloud Apps Activity log retains data for approximately 180 days (about 6 months), visible across the portal and the CloudAppEvents hunting table.
Purview Audit (Standard) retains records for 180 days (changed from 90 days effective October 17, 2023).
Purview Audit (Premium) retains Exchange, SharePoint, OneDrive, and Microsoft Entra audit records for 1 year by default; other activities stay at 180 days.
A 10-year retention add-on is available on top of Premium for organizations with long-term compliance obligations.
For longer Defender for Cloud Apps history, use continuous export to Microsoft Sentinel or a Log Analytics workspace , where the CloudAppEvents table preserves activity data for the workspace retention period.
When a question asks where to find a 9-month-old Microsoft 365 admin action for a compliance audit, the answer is Purview Audit (Premium) or a Sentinel-exported Defender for Cloud Apps stream — not the in-portal Activity log, which has aged the record out.