SC-300 · Domain 3 of 4

SC-300 Domain 3: Plan and implement workload identities

Giving applications and Azure workloads the right identities and access: managed identities, enterprise app settings and consent, application proxy and SaaS integration, app registrations with permissions and roles, and monitoring app use with Microsoft Defender for Cloud Apps.

Exam weight
20–25%
Official functional groups
4
Estimated questions estimate
~12
Suggested study time estimate
12–16 hrs

About 13 min read Reviewed October 2026

Overview

Domain 3 deals with non-human identities and the apps people sign in to. Microsoft lists four functional groups with 23 bullet objectives. The first covers choosing between managed identities, service principals, user accounts and managed service accounts, then creating, assigning and using managed identities. The enterprise applications group covers app-level and tenant-level settings, app admin roles, Microsoft Entra application proxy for on-premises apps, SaaS integration, user and group assignment with app roles, user and admin consent, and app collections.

The app registrations group covers planning, creating registrations, configuring authentication such as redirect URIs and credentials, API permissions and app roles. The last group moves into Microsoft Defender for Cloud Apps: cloud discovery, connected apps, application-enforced restrictions, Conditional Access app control, access and session policies, OAuth app policies and the cloud app catalog.

How it's tested

Scenarios here describe an application or Azure workload and an access goal: reach Key Vault without secrets, let users sign in to a SaaS app with SSO, publish an internal web app, stop downloads of sensitive files in unmanaged browsers, or control risky OAuth apps. You choose the identity type, setting, permission or Defender for Cloud Apps policy.

  • No secrets in code

    An Azure resource must call another Azure service, and you choose a system-assigned or user-assigned managed identity plus an RBAC role.

  • Consent control

    Users keep granting permissions to unknown apps, and you restrict user consent and enable the admin consent workflow.

  • Session-level protection

    Sensitive downloads must be blocked on unmanaged devices, and you combine Conditional Access app control with a session policy.

Reasoning it through

Twenty web apps in Azure App Service all need read access to the same storage account, and the identity must survive app redeployment. A system-assigned identity is tied to each app's lifecycle and would require twenty role assignments that disappear when an app is deleted. A user-assigned managed identity is created once, attached to every app, and granted one Storage Blob Data Reader role, so it is the better choice.

Functional groups 4

Official functional groups from the Microsoft outline, in outline order.

3.1 Plan and implement identities for applications and Azure workloadsChoosing workload identity types and using managed identities.
What it means
This group covers selecting the right identity for an application or Azure workload from managed identities, service principals, user accounts and managed service accounts, creating managed identities, assigning them to Azure resources, and using them to access other Azure resources such as Key Vault, Storage or SQL.
What to understand
Managed identities are service principals whose credentials Azure manages, so code obtains tokens without stored secrets. System-assigned identities live and die with one resource; user-assigned identities are standalone resources that several resources can share. Access is granted through Azure RBAC role assignments or service-specific permissions. A service principal with a certificate or secret, or with workload identity federation, suits apps running outside Azure such as GitHub Actions. Group managed service accounts belong to on-premises AD for Windows services. User accounts should not be used as service identities because they carry passwords, MFA and licensing problems.
How it shows up
Expect a workload description and a choice among identity types, or the step needed after enabling an identity.
Common confusion
Enabling a managed identity and assuming it already has access; a role assignment is still required.
3.2 Plan, implement, and monitor the integration of enterprise applicationsEnterprise app settings, admin roles, application proxy, SaaS SSO, assignment, consent and collections.
What it means
This group covers configuring application-level and tenant-level settings for enterprise applications, assigning roles such as Application Administrator or Cloud Application Administrator, publishing on-premises web apps with Microsoft Entra application proxy, integrating SaaS apps with SSO and provisioning, assigning users, groups and app roles, managing user and admin consent, and creating app collections in My Apps.
What to understand
An enterprise application is the service principal in your tenant. Assignment required set to Yes means only assigned users and groups can get tokens. SaaS integration usually uses SAML or OpenID Connect for SSO plus SCIM for automatic provisioning. Application proxy publishes internal web apps through outbound-only private network connectors, with preauthentication by Entra ID and Kerberos constrained delegation for Windows-authenticated apps. User consent settings can allow consent only for verified publishers with low-impact permissions, or block it, and the admin consent workflow routes requests to reviewers. Cloud Application Administrator cannot manage application proxy, while Application Administrator can.
How it shows up
Expect a consent risk to control, an internal app to publish without VPN, or the least-privileged role to manage SSO for a SaaS app.
Common confusion
Confusing app registration owners with enterprise app owners, or thinking Cloud Application Administrator can configure application proxy.
3.3 Plan and implement app registrationsRegistration planning, authentication settings, API permissions and app roles.
What it means
This group covers planning when an application needs its own registration, creating app registrations, configuring authentication with platform settings, redirect URIs, supported account types and credentials, configuring API permissions with delegated or application scope, and defining app roles that appear in tokens.
What to understand
An app registration is the global application object in the home tenant, and each tenant that uses it gets a service principal. Supported account types decide whether the app is single-tenant, multitenant or also open to personal Microsoft accounts. Delegated permissions act on behalf of a signed-in user and are capped by that user's own rights; application permissions act as the app itself and always need admin consent. Certificates or federated credentials are preferred over client secrets. App roles defined in the manifest can be assigned to users, groups or other apps and are delivered in the roles claim for authorization decisions inside the app.
How it shows up
Expect choices between delegated and application permissions, account type for a multitenant app, or app roles versus groups claims.
Common confusion
Thinking delegated permissions let an app exceed the signed-in user's own access.
3.4 Manage and monitor app access by using Microsoft Defender for Cloud AppsCloud discovery, connected apps, session control, policies, OAuth apps and the catalog.
What it means
This group covers configuring and analyzing cloud discovery, connecting apps through API connectors, implementing application-enforced restrictions, configuring Conditional Access app control, creating access and session policies, implementing and managing OAuth app policies, and managing the cloud app catalog with sanctioned and unsanctioned tags.
What to understand
Cloud discovery analyzes traffic logs or Microsoft Defender for Endpoint data to reveal shadow IT, and apps marked unsanctioned can be blocked through Defender for Endpoint. App connectors use vendor APIs for visibility and governance of connected apps such as Microsoft 365 or Salesforce. Conditional Access app control routes sessions through a reverse proxy when a Conditional Access policy uses the custom session control, enabling session policies that block downloads, apply labels or monitor activity. Access policies allow or block sign-in to the app. Application-enforced restrictions rely on the app itself, such as SharePoint limited access for unmanaged devices. OAuth app policies flag or revoke apps with high-risk permissions or low community use.
How it shows up
Expect a choice among discovery, API connector, session policy and OAuth policy for a stated monitoring or control need.
Common confusion
Expecting a session policy to work without a Conditional Access policy that routes the session to app control.

High-yield concepts

The terms, rules and formulas this domain turns into questions most often.

  • System-assigned managed identity

    Identity bound to one Azure resource's lifecycle.

    Remember
    Deleted with the resource.
    Tested as
    Single-resource access questions.
    Trap
    Sharing it across resources.

  • User-assigned managed identity

    Standalone identity attachable to many resources.

    Remember
    Survives resource deletion and redeployment.
    Tested as
    Shared access questions.
    Trap
    Expecting it to be created automatically.

  • Workload identity federation

    Trust that lets external workloads exchange their token for an Entra token.

    Remember
    Removes stored secrets for GitHub Actions or Kubernetes.
    Tested as
    CI/CD identity questions.
    Trap
    Rotating client secrets instead.

  • App registration vs enterprise application

    Application object in the home tenant versus service principal in each tenant.

    Remember
    Permissions are consented on the service principal.
    Tested as
    Multitenant app questions.
    Trap
    Thinking they are separate apps.

  • Delegated permission

    Permission the app uses on behalf of a signed-in user.

    Remember
    Effective access is the intersection of app and user rights.
    Tested as
    Permission type questions.
    Trap
    Assuming it bypasses user rights.

  • Application permission

    Permission the app uses as itself without a user.

    Remember
    Always requires admin consent.
    Tested as
    Daemon and background job questions.
    Trap
    Letting users consent to it.

  • Admin consent workflow

    Lets users request admin approval for apps they cannot consent to.

    Remember
    Designated reviewers approve or deny.
    Tested as
    Consent governance questions.
    Trap
    Leaving users blocked without a request path.

  • App roles

    Roles defined by the app and assigned to users, groups or apps.

    Remember
    Returned in the roles claim.
    Tested as
    Authorization design questions.
    Trap
    Using directory roles for in-app permissions.

  • Microsoft Entra application proxy

    Publishes on-premises web apps through outbound connectors with Entra preauthentication.

    Remember
    Needs no inbound firewall rules.
    Tested as
    Hybrid app access questions.
    Trap
    Using it for non-HTTP protocols.

  • Conditional Access app control

    Defender for Cloud Apps reverse proxy that enforces session policies.

    Remember
    Triggered by a Conditional Access session control.
    Tested as
    Download control questions.
    Trap
    Configuring only the session policy.

  • Cloud discovery

    Analysis of network or endpoint logs to find cloud apps in use.

    Remember
    Integrates with Defender for Endpoint for blocking.
    Tested as
    Shadow IT questions.
    Trap
    Expecting it to control sessions.

  • OAuth app policy

    Defender for Cloud Apps policy that detects risky OAuth apps.

    Remember
    Can revoke app access automatically.
    Tested as
    Consent abuse questions.
    Trap
    Relying only on Entra consent settings after grants exist.

Side by side

Concepts candidates mix up, compared on the point that decides the answer.

Workload identity types

ConceptMeaningKey differenceCommon trap
System-assigned managed identity Tied to one Azure resource Lifecycle matches the resource Assigning it to multiple resources
User-assigned managed identity Separate Azure resource Shared across resources Forgetting the RBAC role
Service principal with certificate or federation App identity for workloads outside Azure Works anywhere a token can be requested Using client secrets with long expiry
Group managed service account On-premises AD service account Windows services on domain-joined servers Choosing it for Azure resources

Permission types

ConceptMeaningKey differenceCommon trap
Delegated App acts for a signed-in user Limited by the user's rights Expecting it to work without a user
Application App acts as itself Admin consent always required Granting it to user-facing SPAs

Defender for Cloud Apps controls

ConceptMeaningKey differenceCommon trap
Cloud discovery Finds apps from traffic logs Visibility of unsanctioned apps Expecting real-time blocking
App connector API connection to a sanctioned app Governance of data at rest Using it for session control
Session policy Real-time control through the reverse proxy Blocks downloads or applies labels Missing the Conditional Access routing policy

Exam traps

Each trap is an answer that looks right. Learn the clue that should change your mind.

  1. Service principal secret for Azure workloads

    What candidates pick
    Create an app registration with a client secret for a VM to reach Key Vault.
    Why it looks right
    It is a familiar pattern.
    Why it's wrong
    A managed identity removes secret storage and rotation for Azure-hosted workloads.

    Clue to watch for The workload runs on an Azure resource that supports managed identities.

  2. Global Administrator for app SSO

    What candidates pick
    Assign Global Administrator so a team can configure SaaS SSO.
    Why it looks right
    It guarantees access.
    Why it's wrong
    Cloud Application Administrator or Application Administrator manages enterprise apps with far less privilege.

    Clue to watch for Least privilege is mentioned and the task is app configuration.

  3. Application proxy for RDP

    What candidates pick
    Publish an RDP host through application proxy alone.
    Why it looks right
    Application proxy publishes internal apps.
    Why it's wrong
    Application proxy handles web apps; non-web protocols belong to Microsoft Entra Private Access.

    Clue to watch for The protocol named is RDP, SMB or SSH.

  4. Block user consent completely

    What candidates pick
    Disable all user consent and stop.
    Why it looks right
    It removes the risk.
    Why it's wrong
    Without the admin consent workflow, users have no route to request apps and work stalls or moves to shadow IT.

    Clue to watch for The scenario asks to keep productivity while controlling consent.

  5. Discovery to block downloads

    What candidates pick
    Use cloud discovery to stop downloads from an app.
    Why it looks right
    Discovery sees app usage.
    Why it's wrong
    Discovery is log-based visibility; a session policy through Conditional Access app control blocks downloads in real time.

    Clue to watch for The requirement is real-time control of user actions.

  6. Groups claim for in-app roles

    What candidates pick
    Send all group memberships in the token for app authorization.
    Why it looks right
    Groups already exist.
    Why it's wrong
    App roles are defined by the app, stay small in tokens, and avoid group overage limits.

    Clue to watch for The app needs its own named permission levels.

Answer framework

Use these steps to reason through application and workload identity scenarios in Domain 3.

  1. Decide where the workload runs and whether a human is signed in, since that determines identity type and permission type.
  2. For Azure-hosted code use a managed identity, choosing user-assigned when several resources share access, then grant the narrowest RBAC role.
  3. For apps you build, create a registration with the right account type, prefer certificates or federated credentials, and define app roles.
  4. For third-party or internal apps, configure SSO, provisioning, assignment and consent settings, and publish on-premises web apps through application proxy.
  5. For monitoring and control, pick discovery for visibility, connectors for governance, session policies for real-time control, and OAuth policies for risky grants.

Practice question

A security team wants to stop users downloading confidential files from Salesforce when they use personal, unmanaged devices, while still allowing browser access. Downloads from compliant devices must continue to work. What should the administrator implement?

Want more like this? The SC-300 practice test has questions for every domain.

Checklist

0 of 14

Tick each one you can do without notes. Your ticks stay in this browser.

Study strategy

Split this domain into its Azure half and its Defender half. For the Azure half, use a free Azure subscription linked to your test tenant. Create a VM or function app, enable a system-assigned identity, give it Key Vault Secrets User, and read a secret without credentials. Then create a user-assigned identity and attach it to two resources to see the difference in lifecycle.

Next, register a sample web app, add a redirect URI, define two app roles, request Microsoft Graph delegated and application permissions, and grant admin consent. Compare the app registration with its enterprise application, then change user consent settings and test the admin consent request flow. Add a gallery SaaS app with SAML SSO, and if you can, install a private network connector to publish an internal site through application proxy.

For the Defender half, use a Microsoft 365 E5 trial. Upload a sample firewall log for cloud discovery, connect Microsoft 365, and build a session policy that blocks downloads for an unmanaged test browser. Finish with practice questions that ask you to pick between identity types and between Defender for Cloud Apps controls.

FAQ

How much of SC-300 is Domain 3, Plan and implement workload identities?

Microsoft weights Plan and implement workload identities at 20–25%. It has four functional groups covering managed identities, enterprise apps, app registrations and Defender for Cloud Apps.

Do I have to write application code for Domain 3?

No. You need to understand app registration settings, permissions and tokens conceptually, and configure them in the admin center, not develop applications.

When should I use a user-assigned managed identity?

Use it when several resources need the same access, when the identity must exist before the resource, or when it must survive resource redeployment.

What is the admin consent workflow?

A setting that lets users request access to an app they cannot consent to. Designated reviewers receive the request and can grant tenant-wide admin consent.

Is Defender for Cloud Apps really on an identity exam?

Yes. One functional group covers discovery, connectors, Conditional Access app control, access and session policies, OAuth app policies and the cloud app catalog.

What replaced the name Azure AD Application Proxy?

It is now Microsoft Entra application proxy, and its connectors are called private network connectors, shared with Microsoft Entra Private Access.

Other Cybersecurity certifications

Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.

Test your Domain 3 knowledge

You have covered managed identities, enterprise apps, consent, app registrations and Defender for Cloud Apps. See whether you can pick the right identity and control under timed conditions.

Take the SC-300 practice test Check your SC-300 readiness

Keep going