This chapter covers Microsoft Defender for Cloud Apps policies, a critical component for securing cloud applications in hybrid and multi-cloud environments. On the SC-200 exam, this topic appears in approximately 15% of questions, especially in the 'Mitigate threats using Microsoft Defender for Cloud' domain. You will be tested on policy types, creation, configuration, and integration with other Microsoft security tools. Mastering these policies is essential for detecting and controlling risky behaviors, shadow IT, and data exfiltration in cloud apps.
Jump to a section
Defender for Cloud Apps policies are like a bank teller named Alex who has a set of strict rules to detect and prevent fraud. Alex sits at the entrance of a bank, monitoring every transaction in real time. Alex has a rulebook: if a customer withdraws more than $10,000, Alex must ask for additional ID and call the manager. If a customer tries to access a safety deposit box after hours, Alex denies entry and logs the attempt. If a customer logs in from a foreign IP address and immediately requests a large wire transfer, Alex flags the transaction and holds it until verification. Alex also has a 'shadow IT' rule: if an employee brings in a personal USB drive, Alex confiscates it and reports to compliance. The rulebook is customizable—Alex can add new rules, set thresholds, and define actions (allow, block, alert). Alex logs every action in a ledger for audits. Similarly, Defender for Cloud Apps policies monitor user activities, apply conditional access rules, and enforce actions based on risk levels, all while logging to Microsoft 365 Defender.
What is Defender for Cloud Apps?
Microsoft Defender for Cloud Apps (formerly Microsoft Cloud App Security) is a Cloud Access Security Broker (CASB) that provides visibility, control, and protection for cloud applications. It integrates with Microsoft and third-party cloud services like Salesforce, Dropbox, AWS, and Google Workspace. Policies are the core mechanism to enforce security rules.
Why Policies Exist
Cloud apps introduce new attack surfaces: unmanaged devices, privileged accounts, third-party apps, and data sharing. Policies automate threat detection and response. They help you:
Detect anomalous behavior (e.g., impossible travel)
Control data exfiltration (e.g., mass download)
Identify shadow IT (e.g., unsanctioned app usage)
Govern app permissions (e.g., OAuth apps)
Types of Policies
Defender for Cloud Apps offers several policy types, each serving a distinct purpose:
Activity Policy: Monitors user activities in real time. Triggers on specific actions (e.g., download > 100 files, login from a new IP). Can apply filters like user, IP range, device tag, app, action type. Actions: alert, block, require MFA, require re-authentication, suspend user, govern (e.g., remove external sharing).
Anomaly Detection Policy: Uses machine learning to detect unusual patterns. Examples: Impossible travel, ransomware activity, suspicious inbox forwarding, unusual file downloads. These are built-in but can be tuned.
File Policy: Scans files for sensitive content using DLP engines. Triggers on conditions like file name, metadata, content (via built-in DLP or custom expressions). Actions: alert, block, quarantine, apply retention label, govern (e.g., revoke sharing).
Session Policy: Works with Microsoft Defender for Endpoint (MDE) and Conditional Access App Control to monitor and control user sessions in real time. Can block downloads, restrict access, or require approval. Requires AAD Conditional Access integration.
OAuth App Policy: Detects and manages permissions granted to third-party OAuth apps (e.g., an app with read/write access to mailboxes). Can alert or revoke permissions.
Malware Detection Policy: Built-in, uses threat intelligence to detect malicious files uploaded to cloud apps. Generates alerts.
Cloud Discovery Policy: Identifies shadow IT by analyzing traffic logs from network proxies or endpoints. Can block unsanctioned apps or alert on risky apps.
App Discovery Policy: Similar to Cloud Discovery but focuses on app metadata and risk scoring.
How Policies Work Internally
Data Ingestion: Defender for Cloud Apps ingests data from:
- API connectors (direct integration with cloud apps like Office 365, Azure, AWS) - Log collectors (for on-premises proxies) - Microsoft Defender for Endpoint (for endpoint traffic) - Conditional Access App Control (for session control)
Policy Evaluation Engine: Each policy is evaluated against every event. The engine checks filters (user, app, IP, device, action) and conditions (thresholds, timeframes). For file policies, it also inspects content via DLP.
3. Actions and Governance: When a policy matches, it executes actions. Actions can be: - Alert: Sends notification to security team. - Block: Prevents the action (e.g., blocks download, blocks login). - Require MFA: Enforces step-up authentication. - Require re-authentication: Forces user to re-login. - Suspend user: Disables user account (requires appropriate permissions). - Govern: Applies actions like remove external sharing, remove collaborator, quarantine file, apply retention label, revoke OAuth app permissions.
Logging and Investigation: All policy matches are logged in the Activity log, Alerts, and Incident queue in Microsoft 365 Defender. Analysts can investigate using the investigation tools.
Key Configuration Parameters
Policy severity: Low, Medium, High. Affects alert priority.
Policy filters:
- User groups (e.g., 'All users', 'External users') - IP address ranges (e.g., corporate IPs vs. anonymous proxies) - Device tags (e.g., 'Compliant', 'Domain joined') - App (e.g., 'Office 365', 'Salesforce') - Activity type (e.g., 'Download file', 'Login') - Thresholds: For example, 'Repeat count' = 5 times in 10 minutes. - Time frame: For rate-based policies (e.g., 'More than 10 downloads in 5 minutes'). - Content inspection: For file policies, you can use built-in DLP expressions or custom regex. You can choose to inspect only files with specific extensions.
Integration with Other Technologies
Microsoft 365 Defender: Alerts appear in the unified incident queue. Policies can trigger automated investigation and response (AIR).
Azure AD Conditional Access: Session policies require Conditional Access to redirect traffic to Defender for Cloud Apps. You must create a Conditional Access policy that uses 'Use Conditional Access App Control'.
Microsoft Purview Information Protection: File policies can apply sensitivity labels or retention labels.
Microsoft Defender for Endpoint: Provides device context and can be used as a source for cloud discovery.
Azure Sentinel: Can ingest alerts from Defender for Cloud Apps for advanced correlation.
Example: Creating an Activity Policy to Block Mass Downloads
In Microsoft 365 Defender, go to Cloud Apps > Policies > Policy management.
Click 'Create policy' and select 'Activity policy'.
Name: 'Block mass download from SharePoint'.
Severity: High.
Category: DLP.
Filters: App = 'SharePoint Online', Activity type = 'Download file'.
Conditions: When repeated activity > 10 times in 5 minutes.
Actions: Block, Alert.
Governance: Suspend user (optional).
Save.
Verification and Monitoring
Use the Activity log to see blocked activities.
Check Alerts for policy violations.
Use the 'Policy' tab in the investigation to see which policies matched.
Use APIs to export policy data.
Default Policies
Defender for Cloud Apps includes default policies like: - 'Impossible travel' (anomaly detection) - 'Activity from anonymous IP addresses' - 'Activity from infrequent country' - 'Suspicious inbox forwarding' - 'Mass download by a single user'
These are enabled by default but can be customized or disabled.
Performance and Scale Considerations
Policies are evaluated in near real-time (seconds to minutes).
High volume of activities might cause delays.
Use specific filters to reduce noise.
Avoid overly broad policies that trigger on every event.
Use the 'Alert' action for investigation, 'Block' for confirmed threats.
Troubleshooting
Policy not triggering? Check filters, ensure the app is connected via API.
Actions not taking effect? Verify permissions (e.g., to suspend user).
Session policies not working? Ensure Conditional Access policy is configured correctly.
Exam Tip: Know the difference between Activity and Session policies. Activity policies are for post-event detection; Session policies are for real-time control.
Connect Cloud Apps via API
To monitor a cloud app, you must first connect it using an API connector. In Defender for Cloud Apps, go to 'Connected apps' and select the app (e.g., Office 365, Salesforce). Follow the authentication flow to grant permissions. This allows Defender to ingest activities and files. For Office 365, you need Global Admin or Security Admin role. The connection polls for events every few minutes. Without this, policies cannot see activities.
Define Policy Filters and Conditions
When creating a policy, you set filters to narrow down which activities or files to evaluate. For example, filter by app (SharePoint), user group (All users), and IP range (Exclude corporate IPs). Conditions define thresholds: 'More than 10 downloads in 5 minutes' or 'File contains credit card number'. The policy engine checks each event against these filters first; if it matches, it then evaluates conditions. Use precise filters to avoid false positives.
Choose Actions and Governance
After conditions are met, the policy executes actions. Actions can be immediate (Block, Alert) or governance (Remove external sharing, Quarantine file). Governance actions require app-specific permissions. For example, to suspend a user, you need appropriate admin roles in the target app. You can combine multiple actions: alert and block, or alert and govern. The order is simultaneous.
Enable and Test the Policy
Once configured, enable the policy. Test by simulating the activity (e.g., download files from SharePoint). Check the Activity log to see if the policy triggered. Use the 'Test' mode if available (some policies allow you to test without blocking). Verify alerts appear in Microsoft 365 Defender. If the policy doesn't trigger, review filters and ensure the app is connected.
Monitor and Tune Policies
After deployment, monitor alerts and fine-tune policies. Too many false positives? Adjust thresholds or add exclusions. Use the 'Policy matches' report to see which policies fire most. Tune severity levels. Regularly review default policies. For example, 'Impossible travel' might need adjustments for global teams. Use the 'Alert' queue to investigate incidents.
Scenario 1: Preventing Data Exfiltration from SharePoint
A large enterprise with 10,000 users allows employees to store sensitive data in SharePoint Online. The security team notices that some users download hundreds of files in a short period before leaving the company. They create an Activity Policy: 'Mass download from SharePoint' with condition 'More than 50 file downloads in 10 minutes' from a single user. Action: Block the download and alert the SOC. Additionally, they add a governance action to suspend the user if the threshold is exceeded twice in a day. This policy reduces data loss incidents by 80%. In production, they had to fine-tune the threshold because some legitimate users (e.g., data analysts) download many files. They added an exception for a specific group of analysts.
Scenario 2: Controlling Shadow IT with Cloud Discovery
A mid-size company uses Defender for Cloud Apps to discover unsanctioned cloud apps. They deploy a log collector on their network proxy to upload traffic logs. The Cloud Discovery policy automatically categorizes apps by risk score (e.g., high-risk apps like file-sharing sites). They create a policy that alerts when a user accesses a high-risk app more than 5 times a day. The security team then blocks those apps at the proxy. They also use the policy to generate a weekly report for management. A common issue is that the log collector can become overwhelmed if the proxy generates millions of logs; they had to set a sampling rate of 1:10 to reduce load.
Scenario 3: Securing Third-Party OAuth Apps
A financial services firm notices that many employees grant permissions to third-party apps (e.g., a calendar scheduling tool) that request read/write access to mailboxes. They create an OAuth App Policy that alerts when an app has high permissions (e.g., read/write mailbox) and is not on an approved list. The policy also automatically revokes permissions for apps with a community rating of 'low'. They had to customize the policy to exclude Microsoft-owned apps. The challenge was that some legitimate apps were flagged; they created an approved app list to whitelist them.
What SC-200 Tests on Defender for Cloud Apps Policies
The SC-200 exam covers this topic under domain 'Mitigate threats using Microsoft Defender for Cloud' (20-25%). Specific objectives:
Create and manage policies for cloud apps (Activity, File, Session, OAuth, Anomaly Detection)
Configure Cloud Discovery policies
Integrate with Conditional Access App Control
Interpret alerts and incidents
Common Wrong Answers and Why Candidates Choose Them
'Session policies can be created without Conditional Access' – This is false because session policies require Azure AD Conditional Access to redirect traffic. Candidates think session control is standalone, but it relies on CA.
'Activity policies block actions in real time' – Activity policies can block, but they are not real-time for all apps. Blocking works only for apps that support API-based blocking (e.g., Office 365). For other apps, they only alert. Candidates confuse Activity with Session policies.
'File policies can inspect all file types by default' – False. File policies only inspect files with extensions that are supported (e.g., .docx, .pdf, .txt). You must configure content inspection to scan for sensitive data. Candidates assume all files are scanned.
'Anomaly detection policies are customizable for any behavior' – Built-in anomaly detection policies are predefined; you can only enable/disable and adjust sensitivity. You cannot create custom anomaly policies. Candidates think they can create custom ML models.
Specific Numbers and Values on the Exam
The default 'Impossible travel' policy uses a time window of 2 hours and a distance threshold of 500 miles.
Session policies require a Conditional Access policy with 'Use Conditional Access App Control' set to 'Monitor only' or 'Block downloads'.
The maximum number of policy filters you can combine is not explicitly limited, but performance degrades with many filters.
The default alert limit is 100 alerts per policy per day (can be changed).
Edge Cases and Exceptions
If a user is a member of multiple groups, policy filters evaluate all groups. If any group matches, the policy applies.
For OAuth app policies, the 'App permission level' filter includes 'Low', 'Medium', 'High'. 'High' means the app has permissions like read/write mailbox.
When using 'Block' action, the user sees a generic error message; you cannot customize it.
Cloud Discovery policies require that you upload logs from a proxy or endpoint; they do not work with API connectors alone.
How to Eliminate Wrong Answers
If the question mentions real-time control, look for 'Session policy' not 'Activity policy'.
If it mentions blocking a download, check if the app supports API blocking; if not, the answer is 'Alert only'.
For questions about shadow IT, think 'Cloud Discovery policy' not 'Activity policy'.
If the question involves machine learning, it's likely 'Anomaly detection policy' (built-in).
Defender for Cloud Apps policies include Activity, Session, File, OAuth App, Anomaly Detection, Cloud Discovery, and Malware Detection.
Session policies require Azure AD Conditional Access with 'Use Conditional Access App Control'.
Activity policies can block actions only for apps that support API-based blocking (e.g., Office 365).
File policies use content inspection to scan for sensitive data; only files with supported extensions are scanned.
Anomaly detection policies are built-in and cannot be custom-created; you can only adjust sensitivity.
Cloud Discovery policies rely on traffic logs from proxies or endpoints, not API connectors.
Default 'Impossible travel' policy uses 2-hour window and 500-mile distance threshold.
OAuth App policies can automatically revoke permissions for high-risk apps.
Policies can be integrated with Microsoft 365 Defender for unified incident management.
Always test policies in a controlled environment before wide deployment.
These come up on the exam all the time. Here's how to tell them apart.
Activity Policy
Monitors activities post-event; can block in real time only for supported apps.
Evaluates activities like login, download, share.
Does not require Conditional Access.
Can apply governance actions like suspend user.
Best for detection and response after the fact.
Session Policy
Monitors and controls sessions in real time.
Can block downloads, restrict access, require MFA during session.
Requires Azure AD Conditional Access policy.
Cannot apply governance actions like suspend user.
Best for conditional access and data protection during active sessions.
Mistake
Session policies work without Azure AD Conditional Access.
Correct
Session policies require a Conditional Access policy to redirect traffic to Defender for Cloud Apps. Without it, session control cannot intercept user sessions.
Mistake
Activity policies can block actions in any cloud app.
Correct
Blocking works only for apps that support API-based blocking (e.g., Office 365, Azure AD). For other apps, Activity policies can only alert.
Mistake
File policies automatically scan all files in connected apps.
Correct
File policies only scan files that match the filter criteria (e.g., file extensions, size). You must configure content inspection to scan for sensitive data.
Mistake
You can create custom anomaly detection policies from scratch.
Correct
Anomaly detection policies are built-in and only allow tuning of sensitivity and enabling/disabling. You cannot create new ML-based anomaly policies.
Mistake
Cloud Discovery policies require API connectors.
Correct
Cloud Discovery policies work by analyzing traffic logs from proxies or endpoints. API connectors are for direct app monitoring, not for discovery.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
An Activity policy monitors user actions after they occur (post-event) and can alert or block in real time only if the app supports API-based blocking. A Session policy, on the other hand, intercepts user sessions in real time, allowing you to control actions like downloads or access while the session is active. Session policies require Azure AD Conditional Access to redirect traffic. For the exam, remember: Activity = event-based, Session = real-time session control.
No, anomaly detection policies in Defender for Cloud Apps are built-in and based on Microsoft's machine learning models. You can enable or disable them and adjust the sensitivity level, but you cannot create new anomaly detection policies from scratch. If you need custom behavioral rules, use an Activity policy with specific thresholds.
Create an Activity policy with filter App = 'SharePoint Online' and Activity type = 'Download file'. Set a condition like 'Repeated activity > 10 times in 5 minutes'. Under Actions, select 'Block' and 'Alert'. Ensure the app is connected via API. The block action will prevent the user from downloading more files once the threshold is exceeded.
Cloud Discovery policies identify shadow IT by analyzing traffic logs from network proxies or endpoints. You upload logs (e.g., from a firewall) or use Microsoft Defender for Endpoint to gather traffic data. The policies categorize apps by risk score and can alert or block access to unsanctioned apps. They do not use API connectors.
Yes, Defender for Cloud Apps requires a license, either standalone or as part of Microsoft 365 E5/A5/G5 or Microsoft 365 E5 Security. Some features like session policies require additional licensing for Conditional Access App Control. Check your license plan for exact entitlements.
You can use the policy's 'Test mode' if available (e.g., for some activity policies, you can set the action to 'Alert' only). Alternatively, create a policy with a filter for a test user group. Monitor the Activity log to see if the policy would have triggered, without taking blocking actions.
The user receives a generic error message (e.g., 'Access denied') and the action is not performed. The event is logged in the Activity log with a 'Blocked' status. An alert is generated if configured. For session policies, the user may see a message that the action is not allowed.
You've just covered Defender for Cloud Apps Policies — now see how well it sticks with free SC-200 practice questions. Full explanations included, no account needed.
Done with this chapter?