15.3 Interpreting the Activity Log

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:

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.