11.1 Cloud Discovery & Connected Apps
Key Takeaways
- Microsoft Defender for Cloud Apps (MDCA) is the cloud access security broker (CASB) that gives identity admins visibility into sanctioned and unsanctioned SaaS usage for SC-300 Domain 3 workload and app scenarios.
- Cloud Discovery analyzes traffic logs (and related signals) to surface shadow IT apps, usage volume, and risk—before you decide to sanction, block, or monitor an app.
- The Cloud App Catalog is Microsoft’s risk-scored library of cloud apps; scores and attributes help you evaluate whether an app is appropriate for your organization.
- Connected apps use API connectors (app connectors) to sanctioned SaaS platforms so Defender for Cloud Apps can pull deeper telemetry and apply governance beyond discovery alone.
- Identity admins care because SaaS sign-ins, OAuth grants, and Conditional Access App Control all sit on the Entra identity plane—visibility without identity context is incomplete Zero Trust.
Why Defender for Cloud Apps appears on SC-300
Domain 3 of the Microsoft Identity and Access Administrator Associate exam (SC-300)—Plan and implement workload identities—is not only managed identities and app registrations. Microsoft also expects you to monitor and govern cloud apps with Microsoft Defender for Cloud Apps (MDCA) (historically Microsoft Cloud App Security / MCAS).
MDCA is Microsoft’s cloud access security broker (CASB) for SaaS. For an identity admin, it answers questions Conditional Access alone cannot:
- Which cloud apps are users actually using (including shadow IT never registered as enterprise apps)?
- How risky is that SaaS product according to industry and Microsoft signals?
- Can we connect a sanctioned app so we see admin activities, files, and accounts with API depth?
- Can we route sessions through Conditional Access App Control for monitor/block download behavior?
- Which OAuth apps have broad delegated permissions to Microsoft 365 or other data?
| Capability area | Identity-admin value on SC-300 |
|---|---|
| Cloud Discovery | Find unsanctioned SaaS (shadow IT) from traffic/logs |
| Cloud App Catalog | Risk scores, compliance attributes, app metadata |
| Connected apps / API connectors | Deep control and investigation for sanctioned SaaS |
| Access & session policies | Real-time control via Conditional Access App Control (section 11.2) |
| OAuth app policies | Govern third-party app consent risk (section 11.3) |
Cloud Discovery: making shadow IT visible
Cloud Discovery is how Defender for Cloud Apps learns which cloud applications your organization is using—especially apps that never went through a formal procurement or Entra enterprise-app onboarding process.
What “shadow IT” means on the exam
Shadow IT is SaaS (or cloud service) usage that IT/security did not formally approve, inventory, or integrate. Classic exam story:
- Marketing signs up for a free collaboration SaaS with corporate email.
- Engineering stores code snippets in an unsanctioned paste/cloud tool.
- Finance uploads spreadsheets to a consumer file-sharing service.
None of those may appear as carefully configured enterprise applications with SSO—but users still authenticate (often with Entra accounts or personal accounts), move data, and create breach risk. Discovery closes that inventory gap.
How discovery data gets into MDCA
At SC-300 conceptual depth, know the sources, not every collector SKU name:
| Source pattern | What it contributes |
|---|---|
| Traffic logs / firewall / proxy / secure web gateway logs | Uploaded or streamed logs that MDCA parses for cloud app destinations |
| Microsoft Defender for Endpoint / network signals (where integrated) | Endpoint-observed cloud app usage that enriches discovery |
| Cloud Discovery snapshot / continuous reports | Aggregated app usage, users, IP addresses, traffic volume |
| Manual investigation of discovered apps | Promote to sanctioned, unsanctioned, or monitored stance |
Traffic logs are the classic CASB story: your network edge sees HTTPS destinations; MDCA maps those destinations to known apps in the Cloud App Catalog, then ranks usage and risk. Without some form of discovery data, you only see apps that happen to be enterprise apps or connected apps—you miss the long tail of shadow SaaS.
Analyzing discovery results
When exam stems say “analyze Cloud Discovery,” they want outcomes such as:
- Identify top apps by user count, traffic volume, or risk.
- Evaluate whether an app is already sanctioned in your catalog tagging.
- Tag apps as sanctioned, unsanctioned, or monitored (organizational stance).
- Create policies (for example discovery policies that alert when a new high-risk app appears).
- Feed decisions into Conditional Access, block at proxy/SWG, or start a formal app onboarding project.
| Discovery question | Example decision |
|---|---|
| High usage + low risk + business need | Start connected app / SSO project; mark sanctioned |
| Low usage + high risk + sensitive data classes | Mark unsanctioned; block or educate; remove OAuth grants |
| Unknown app spiking overnight | Investigate anomaly; check compromised accounts or rogue automation |
| Many personal instances of a file-sharing brand | Prefer enterprise tenant of a sanctioned alternative |
Exam trap: discovering an app is not the same as connecting it via API. Discovery is inventory and risk insight; API connectors (connected apps) are a separate, deeper integration for supported platforms.
Cloud App Catalog
The Cloud App Catalog is Microsoft’s large library of known cloud applications. Each entry can include:
- App identity and categories (collaboration, CRM, storage, social, and so on).
- Risk score (composite score based on security, compliance, and industry factors—exact weighting evolves; exam cares that lower risk is better and scores guide sanction decisions).
- Security attributes (for example encryption, auditability, certifications where published).
- Whether the app can be connected (API connector support) or used with Conditional Access App Control patterns.
| Catalog concept | SC-300 use |
|---|---|
| Find an app | Search by name to see risk and capabilities |
| Risk score | Compare alternatives (for example two file-sharing SaaS products) |
| Custom / manually added apps | Represent internal or obscure apps when needed for proxy/control scenarios |
| Domains | Associate custom domains/plugins so discovery and control map correctly |
Identity admins use the catalog when stakeholders say “we want App X.” You check risk, connector support, and whether Entra SSO gallery/enterprise-app integration exists—then design CA + MDCA controls around that choice.
Connected apps and API connectors
Connected apps (also discussed as app connectors / API connectors) link Defender for Cloud Apps to a sanctioned SaaS platform using that platform’s APIs—often with an administrator consent flow that creates or uses an application identity in the SaaS or in Microsoft Entra.
Why connect beyond discovery?
| With discovery only | With API connector (connected app) |
|---|---|
| See that users hit the SaaS | See accounts, files, activities, admin events (app-dependent) |
| Coarse usage volumes | Richer investigation and policy automation |
| Harder to govern inside the app | Quarantine files, suspend users, revoke permissions (where supported) |
| Shadow IT focus | Sanctioned app governance focus |
Typical connected-app scenarios on SC-300-style stems:
- Connect Microsoft 365 / SharePoint / OneDrive style workloads for file and activity visibility (product naming evolves; concept is first-party Microsoft workload depth).
- Connect popular third-party SaaS (CRM, collaboration, storage brands that support connectors) after business formalizes them as sanctioned.
- Investigate a compromised user by reviewing activities across connected apps.
- Apply information protection / session governance more intelligently when the app is both discovered and connected.
Admin flow (conceptual)
- Confirm the app is business-sanctioned (or pilot-sanctioned).
- In Defender for Cloud Apps settings, open Connected apps / app connectors.
- Start the connector and complete admin consent / API authorization for required permissions.
- Wait for initial data pull; validate activities and accounts appear.
- Build policies that depend on connected-app signals (activity policies, file policies, and so on—depth varies by exam item).
- Keep the connector healthy: credential/consent expiry, permission changes, and SaaS admin role requirements matter operationally.
| Role of Entra identity | Role of MDCA connector |
|---|---|
| Users sign in with Entra (SSO) | Connector pulls SaaS management/activity data |
| Conditional Access evaluates sign-in | Session control may reverse-proxy the session (11.2) |
| Enterprise app assignment / roles | In-app SaaS roles still exist in the SaaS console |
| Consent & OAuth grants (11.3) | OAuth app inventory and revoke actions in MDCA |
Why identity admins specifically care about SaaS visibility
SC-300 is an identity exam. Why not leave MDCA to the SOC only?
- Sign-in is the common control point. Users reach SaaS through Entra authentication. If you only secure Entra portals but ignore which SaaS tokens and OAuth apps exist, attackers still exfiltrate via consented apps and unsanctioned tools.
- Conditional Access App Control is configured from Conditional Access (identity plane) but enforced with Defender for Cloud Apps (CASB plane). Identity admins own the CA policy design.
- Consent and enterprise apps live in Entra; OAuth app risk is also surfaced and governed in MDCA. You need both blades for complete app governance (section 11.3).
- Zero Trust requires verifying explicitly for every resource—including SaaS that is not Microsoft 365. Discovery tells you which resources exist in practice.
- Incident response for a risky user often needs SaaS activity timelines from connected apps plus Entra sign-in logs.
| Identity control | MDCA complement |
|---|---|
| Conditional Access grant (MFA, device) | Session policies for download/clipboard after grant |
| Enterprise app user assignment | Discovery of apps never assigned |
| Admin consent workflows | OAuth app policies and permission review |
| Identity Protection risky user | Connected-app activity investigation |
| Access reviews of group membership | Reviews of who uses high-risk SaaS (process design) |
Configuration and analysis checklist for exam scenarios
Walk stems in this order:
- Do we need inventory of unknown SaaS? → Cloud Discovery + traffic/log sources.
- Do we need risk comparison? → Cloud App Catalog scores and attributes.
- Is the app formally allowed? → Tag sanctioned/unsanctioned; align with security policy.
- Do we need deep SaaS telemetry/control? → Connected app / API connector.
- Do we need real-time session control in browser? → Conditional Access App Control (next section).
- Is the risk OAuth consent rather than web session? → OAuth app policies (section 11.3).
| Stem cue | Prefer |
|---|---|
| “Shadow IT,” “unknown cloud apps,” “firewall logs” | Cloud Discovery |
| “Risk score of SaaS product,” “catalog” | Cloud App Catalog |
| “API connector,” “connected app,” “pull activity from Salesforce/ServiceNow/etc.” | Connected apps |
| “Block download in session,” “monitor only session” | CA App Control + session policy |
| “Third-party app permissions,” “revoke OAuth” | OAuth app governance |
Putting section 11.1 together
Security wants a list of cloud SaaS applications employees use that were never onboarded as enterprise apps. Firewall and proxy logs are available. Which Defender for Cloud Apps capability best addresses this SC-300 scenario?
What is the primary purpose of connecting a sanctioned SaaS platform with an API connector (connected app) in Microsoft Defender for Cloud Apps?
An identity admin compares two file-sharing SaaS products before sanctioning one. Which MDCA resource provides risk scores and security attributes for known cloud apps?
Why should an SC-300 identity administrator care about SaaS visibility in Defender for Cloud Apps instead of only managing Entra enterprise applications?