Microsoft SC-300 No-Nonsense Guide

This is a no‑nonsense, exam‑oriented guide for Microsoft Identity and Access Administrator Certification based on the official exam outline and recent updates/practice materials.

Exam basics (pattern, score, types)

• Name: SC‑300 – Microsoft Identity and Access Administrator.​

• Duration: About 120 minutes, typically 40–60 questions.

• Question types: Single-choice, multi-select, drag & drop, hotspot, case studies; some people saw labs earlier in 2024, later sittings often had none (so don’t rely on labs being there).

• Passing score: 700/1000.

• Languages: English + a few others (Japanese, Korean, Simplified Chinese, etc., check the exam page).

Current skills split (after July 25, 2025):​

• Implement and manage user identities – 20–25%

• Implement authentication and access management – 25–30%

• Plan and implement workload identities – 20–25%

• Plan and automate identity governance – 20–25%

Everything below is organized along these 4 areas.

How Microsoft asks SC‑300 questions

Microsoft loves long, wordy scenarios. Common traits:

• They hide the one key phrase: “leaked credentials”, “legacy authentication”, “guest users only need temporary access”, “must not impact existing users”, etc.

• They test whether you know exact product names and features (Identity Protection vs Conditional Access vs PIM vs Access Reviews).​

• They like licensing and “which feature needs P1 vs P2?”, especially CA, Identity Protection, PIM, Access Reviews, Global Secure Access.

Your job in each question:

1. Identify what is being protected (user, sign‑in, app, admin role, data).

2. Map that to the right Entra feature and policy type (CA, PIM, Identity Protection, Access Reviews, Entitlement Mgmt, Global Secure Access).

3. Remember Block always wins in Conditional Access, policies are additive, and report‑only + What‑If are there to avoid self‑lockout.

Core mindset: Zero Trust in Entra

SC‑300 assumes Zero Trust: never trust, always verify, least privilege, assume breach.

You implement Zero Trust in Entra by:

• Strong authentication (MFA, passwordless, Conditional Access).

• Least privilege (Entra roles + PIM, app roles, RBAC for Azure resources).​

• Governance (access reviews, entitlement management, break‑glass accounts).​​

• Monitoring (logs to Log Analytics, Identity Secure Score, Identity Protection).

You will see this logic everywhere in the questions.

How to use this (simple)

• There are 4 big domains.

• Under each domain, Microsoft has bullet points like “configure and manage custom domains”

• I’ll take those bullets one by one, explain in plain terms:

  • What the feature is.

  • What buttons/objects exist.

  • What kind of exam question you’ll see.

You can literally treat this as a checklist: “Can I explain this to myself the way it’s written here?” if yes, you’re good.

Domain 1 – Implement an identity management solution (aka user identities)

1. Configure and manage Entra (Azure AD) directory roles

• What this is: Entra has built‑in admin roles like Global Administrator, User Administrator, Security Administrator, Application Administrator, etc.; these control what people can do in the tenant.learn.microsoft+1

• Core idea: Instead of giving everyone full god‑mode, you give just enough permission by assigning them a specific role.

What you must know:

• “Global Administrator” (a.k.a. Company Administrator) can do everything in Entra.

• “User Administrator” manages users and groups but can’t necessarily manage everything security‑related.

• Roles are assigned to users, groups, and service principals; assignments can be permanent or “eligible” (when using PIM).

Exam angle:

• “You must allow a helpdesk team to reset passwords but not manage Conditional Access.” → Assign Helpdesk Administrator or Password Administrator, not Global Administrator.

• “Regional admin should only manage users in India OU” → Use Administrative Units + scoped role (we’ll cover AUs later).

2. Configure and manage custom domains

• What this is: By default your tenant is something like contoso.onmicrosoft.com; you add contoso.com as a custom domain so usernames and email look normal.

You must understand:

• Steps in plain words:

  • Add domain name in Entra.

  • Prove ownership by adding DNS record (TXT, sometimes MX).

  • After verification, you can set it as primary so future users are name@contoso.com.learn.microsoft+1

• Important: You must verify the domain before using it for UPNs and email.

Exam angle:

• “User logons should be @contoso.com instead of @contoso.onmicrosoft.com.” → Answer involves adding and verifying custom domain and making it primary.

3. Configure and manage device registration options

• What this is: Devices (PCs, phones) can be:

  • Entra registered (BYOD, personal)

  • Entra joined (corporate, cloud‑only)

  • Hybrid Entra joined (on‑prem AD joined + visible in Entra).

Key points:

• In Entra, you can control who can register devices, max devices per user, and if MDM (Intune) should auto‑enroll devices.

• Entra‑joined devices are used for SSO + Conditional Access for compliant devices + Windows Hello for Business.

Exam angle:

• “Only IT should be able to register devices.” → Change device settings so users cannot register devices; only admins do.

• “Differentiate personal vs corporate device in CA policy.” → Use device state / device filter condition and know that Entra‑registered = BYOD, Entra‑joined = corporate.

4. Configure delegation using Administrative Units

• What this is: Administrative Units (AUs) let you carve tenant into pieces (for example by region or department) and assign admin roles just for that slice.

You must be able to explain:

• AU = container for users and groups, not resources like VMs.

• You can give someone “User Administrator” only for that AU (like only “India staff”).

Exam angle:

• Wording like: “Admin in Paris must manage only users in the France division, not entire tenant.” → Use Administrative Unit + scoped Entra role.

5. Configure tenant‑wide settings

• What this is: Global toggles impacting the whole tenant: who can create security groups, who can invite guests, default user features, etc.

Examples:

• Limit self‑service sign‑up.

• Control if users can register applications or only admins can.

• Configure group creation (for example who can create Microsoft 365 groups).

Exam angle:

• “Users are creating apps that bypass governance; you must prevent non‑admins from registering apps.” → Change tenant setting so only admins/developers can register applications.

6. Create, configure, and manage users

• Includes cloud‑only users and synced users (from on‑prem).

You must be comfortable with:

• Attributes: Display Name, UPN, password, accountEnabled, licenses.

• Bulk operations:

  • CSV upload in Entra.

  • Graph PowerShell:

    • Connect-MgGraph

    • Get-MgUser -All

    • New-MgUser to create.

Exam angle:

• “You need to create 400 users from a list in Excel.” → Use bulk user creation with CSV or Graph PowerShell New‑MgUser, not clicking manually.

7. Create, configure, and manage groups

• Security groups: used for permissions, app access, CA targeting.

• Microsoft 365 groups: plus mailbox, Teams, SharePoint.

Things to know:

• Static vs dynamic groups:

  • Static: you add members manually.

  • Dynamic: membership based on rules (e.g., department -eq "HR").

• You can assign licenses and roles to groups (group‑based licensing).

Exam angle:

• “All HR staff should automatically get access to HR app when joined.” → Use a dynamic group based on department attribute and assign app to that group.

8. Manage licenses

• You can apply licenses:

  • Per user.

  • To groups (group‑based licensing).

Important exam bits:

• Group‑based licensing simplifies large organizations; licensing errors appear if not enough licenses.

• Some features (PIM, Identity Protection, Access Reviews, Entitlement Mgmt) need Entra ID P2

Exam angle:

• “Access Reviews fail because not enough P2 licenses.” → Answer mentions ensuring enough P2 licenses for reviewers and guests.

9. Manage external collaboration settings in Entra (B2B)

• This controls how guests behave in your tenant.

You must know:

• Turn B2B collaboration on/off.

• Limit inviting guests to certain admins or everyone.

• Set what guests can see/do (e.g., visibility of group membership, membership options).

Exam angle:

• “Partners should not see other guest users in the directory.” → Adjust external collaboration settings to restrict guest visibility.

10. Invite external users (individually or bulk)

• Guests (B2B) are added via email invite or bulk CSV.

You must know:

• Invitation flow:

  • Invite → user gets email → accepts → B2B account created (user_domain#EXT#@tenant.onmicrosoft.com).

• Bulk invites using CSV template in portal or Graph.

Exam angle:

• “Allow 200 contractors to access an app without creating accounts manually.” → Bulk invite external users, then assign them to groups/app.

11. Configure identity providers (social and SAML/WS‑Fed)

• For External Identities scenarios, you can allow sign‑in using Google, Facebook, other IdPs using SAML or WS‑Fed.

Key points:

• Social IdPs = e.g., Google.

• Enterprise IdPs = SAML/WS‑Fed or OIDC identity providers.

Exam angle:

• “Allow external customers to sign in using their Google accounts to a portal.” → Use External Identities + configure Google as identity provider, not B2B guest for each user.

12. Implement and manage hybrid identity (Entra Connect / Cloud Sync)

Definitions:

• Azure AD Connect (AADC): sync engine between on‑prem AD and Entra; replicates users/groups.

• Password Hash Sync (PHS): hashes of on‑prem passwords synced up; logons checked in Entra.

• Pass‑Through Authentication (PTA): sign‑ins go back to on‑prem agent to validate credentials.

• Seamless SSO: domain‑joined devices in LAN auto sign‑in with Kerberos, less password prompts.

• Federation: using AD FS or other STS; exam cares about migrating away more than setting it up now.

• Connect Health: monitors sync, PTA, federation health.

Exam angles:

• “Minimize infrastructure while still using on‑prem AD.” → Choose PHS + Seamless SSO instead of complex federation.

• “Identity Protection must detect leaked credentials for on‑prem users.” → Need Password Hash Sync enabled so Entra can compare hashes.

• “Users synced but can’t sign in; sync error in logs.” → Use AADC troubleshooting / Connect Health.

Domain 2 – Authentication and access management

1. Plan Azure MFA deployment (excluding old MFA Server)

• Azure MFA = extra factor like phone app, SMS, calls.

You plan:

• Who must use MFA (all users vs privileged users vs specific groups).

• Whether to use security defaults (simple on/off) or Conditional Access (complex).

• Registration methods allowed (Authenticator app, phone, FIDO2, etc.).

Exam angle:

• “Need MFA only when outside trusted locations, not always.” → Use Conditional Access with location condition, not security defaults.

2. Implement and manage Azure MFA settings

• Configure MFA at tenant level and user level:

  • Enable/disable per user (legacy blade).

  • Set verification methods allowed.

Cheat sheet adds:

• Registration campaign (push users off SMS to Authenticator).

• Authentication strengths: CA policies can require “phishing‑resistant MFA” (FIDO2, etc.).

Exam angle:

• “All admins must use phishing‑resistant MFA.” → Use Authentication strengths in CA policies with appropriate methods allowed.

3. Manage user authentication (Windows Hello, passwordless, SSPR, password protection, tenant restrictions)

a) Administer authentication methods (FIDO2 / passwordless)

• Passwordless options:

  • Windows Hello for Business (PIN/biometrics with strong keys).

  • FIDO2 security keys (hardware keys).

  • Phone sign‑in with Microsoft Authenticator.

You must know that these are configured in Authentication methods policies in Entra.

b) Windows Hello for Business

• Uses device‑bound keys stored in hardware (TPM), no passwords.

• Can be enforced by Intune policies and used as MFA.

c) Self‑Service Password Reset (SSPR)

• Users reset their own passwords if they have registered methods (SMS, email, app, questions).

• For on‑prem writeback, need P1/P2 and AADC configured.

d) Password protection

• Custom banned password lists, smart lockout to resist password spray.

• You configure lockout thresholds and timeouts.

e) Tenant restrictions

• Let you block users from accessing other tenants’ resources from your corporate network/browser.

Exam angle:

• “Users choose weak passwords similar to company name.” → Configure Password protection with banned password list.

• “Need self‑service password reset for cloud users; on‑prem AD unaffected.” → Enable SSPR for specific group, no write‑back required.

4. Plan, implement, and administer Conditional Access

Bullets: security defaults, plan policies, implement controls/assignments, test/troubleshoot, app controls, session management, smart lockout thresholds.

a) Security defaults vs CA

• Security defaults:

  • Free, simple baseline with MFA for all admins, basic protections.

  • On/off only, no customization.

• CA:

  • Requires Entra ID P1.

  • Full policy engine with conditions/controls.

Important: To use CA in a custom way, you usually turn off security defaults first.

b) CA building blocks

• IF (assignments):

  • Users/groups/roles.

  • Cloud apps/actions.

  • Conditions: device platform, locations, client apps (legacy vs modern), sign‑in risk, device filters.

• THEN (controls):

  • Grant: block, or require MFA, require compliant device, require password change, require approved app, etc.

  • Session: sign‑in frequency, persistent browser sessions, app‑enforced restrictions, CA App Control.

c) Testing / troubleshooting CA

• Report‑only mode: policy evaluated but not enforced; result visible in sign‑in logs.

• What If tool: simulate a login with given user, location, app to see which CA policies apply.

d) App controls and session management

• App controls: integration with Defender for Cloud Apps to do session‑level inspection.

• Session controls: enforce re‑auth every X hours, restrict persistent sessions, etc.

e) Smart lockout thresholds

• Smart lockout uses signals to lock accounts under attack while not blocking valid users; thresholds can be adjusted.

Exam angles:

• “Block legacy Office clients that don’t support modern auth.” → CA policy with Client apps = legacy, control = Block access.

• “Test policy impact without locking out users.” → Use Report‑only + What‑If tool.

• “Force sign‑in every 4 hours for high‑risk app.” → Use session sign‑in frequency control.

5. Manage Entra ID Identity Protection

Bullets: user risk policy, sign‑in risk policy, MFA registration policy, monitor & remediate risky users.

Core definitions (again, because this is heavily tested):

• User risk: probability the account is compromised over time (leaked credentials, multiple risky sign‑ins).

• Sign‑in risk: probability that a specific login is not the legitimate user (impossible travel, TOR, malware IP, etc.).

Policies:

• User risk policy:

  • Target users/groups.

  • Set risk level (Low/Medium/High).

  • Controls: block access, or allow but require password change (often with MFA).

• Sign‑in risk policy:

  • Target users/groups.

  • Set sign‑in risk threshold.

  • Control: require MFA or block.

• MFA registration policy:

  • Forces users to register MFA methods when they sign in, if they’re not already registered.

Monitoring / remediation:

• Use Identity Protection blade to:

  • View risky users, risky sign‑ins, risk detections.

  • Dismiss, confirm compromise, require secure password change.

Exam angles:

• “Leaked password” or “probability that account is compromised” → User risk policy with password reset.

• “Impossible travel, sign‑in from TOR exit node, but user can continue with extra step” → Sign‑in risk policy requiring MFA.

Domain 3 – Implement access management for apps / workload identities

(Older docs call it “Access management for apps”; newer blueprint calls it workload identities + app access.)

1. Integrate Enterprise Apps for SSO

Bullets: consent settings, discover apps via Cloud App Discovery/ADFS report, design access, design app admin roles, monitor sign‑ins, App Proxy.

a) Consent settings

• Users can sometimes grant apps permission to read their data (“User consent”).

• You can:

  • Allow user consent to low‑impact permissions.

  • Block user consent entirely; require admin consent.

Exam angle:

• “Users are granting risky permissions to third‑party apps.” → Restrict user consent and require admin approval.

b) Discover apps (MCAS / ADFS report)

• Defender for Cloud Apps (“MCAS”) can detect shadow IT and SaaS usage.

• ADFS app reports show which apps rely on ADFS; used for migrating them to Entra SSO.

c) Design and implement access management for apps

• Decide:

  • Which users/groups get the app.

  • Whether app requires user assignment.

  • Apply CA to that specific app.

d) App management roles

• Roles like “Application Administrator”, “Cloud Application Administrator” manage application settings but not entire tenant.

e) Monitor and audit app sign‑ins

• Use Enterprise applications → Sign‑ins to see who accessed which app, from where, success/failure.

f) Application Proxy (on‑prem apps)

• You install an Application Proxy connector on an on‑prem server, which keeps an outbound connection to Entra.

• Then Entra exposes an external URL for that app; you can put SSO & CA in front of it.

Exam angle:

• “Expose on‑prem HR app to remote users without VPN, using central identities and MFA.” → Application Proxy + SSO + CA.

2. Plan and implement workload identities (service principals, managed identities, etc.)

Updated blueprint emphasizes: users vs workload identities; using managed identities and app registrations correctly.

Identity types:

• User account – human, should not be used long‑term by apps.

• Service principal – identity for an app in Entra; created automatically from app registration or by gallery SaaS.

• Managed identity – service principal tied to an Azure resource (VM, Function, Web App).

Rules of thumb:

• Azure tools running inside your subscription (VM, Function, Logic App) → Managed Identity + assign Azure roles to it.

• External script/service → use a service principal with certificate or secret, limit permissions.

Exam angles:

• “Azure Function must read from Key Vault without storing credentials.” → Use managed identity for the Function and give it a Key Vault access policy/RBAC.

• “Background app needs to read all users without user sign‑in.” → Application permission on Microsoft Graph via app registration + admin consent.

3. App registrations & API permissions

Cheat sheet + skills list.

App Registration vs Enterprise app:

• App registration:

  • Developer object with client ID, secrets/certs, API permissions.

• Enterprise application:

  • Service principal instance in your tenant.

Permissions:

• Delegated: require a signed‑in user; app acts on behalf of that user.

• Application: no user; app acts as itself; needs admin consent.

App roles:

• You define roles in app registration (e.g., Reader, Admin).

• You assign app roles to users/groups/service principals to control app’s own authorization.

Exam angle:

• “Daemon app runs without user, reading user data every night.” → Application permission + admin consent.

• “Different users should have different access levels inside custom app.” → Define app roles and assign them.

4. Defender for Cloud Apps / app control

• Detects shadow IT, classifies apps, and enforces policies (session controls, blocking risky apps).

• Integrates with CA: Conditional Access App Control to route sessions through Cloud App Security for inspection and enforcement.

Exam angle:

• “Allow access to SharePoint only with download restrictions on unmanaged devices.” → Use CA for targeting + Defender for Cloud Apps session policies (app‑enforced restrictions).

Domain 4 – Plan and implement an identity governance strategy

Based on the Identity Governance bullets.

1. Entitlement management

Bullets: define catalogs, define access packages, manage entitlements, terms of use, lifecycle of external users.

Concepts with "dummy" language:

• Catalog = bookshelf. It groups resources (groups, apps, SharePoint sites) that belong together (e.g., “HR resources”).

• Access package = bundle of access from a catalog (e.g., “HR Starter Pack” = HR group + HR app + SharePoint).

• Policy inside access package defines:

  • Who can request (internal, guests, specific connected organizations).

  • Who must approve (manager, selected approver, auto).

  • How long they keep access before it expires.

Terms of Use / external lifecycle:

• You attach Terms of Use PDFs that users must accept.

• For guests, you can set rules to auto‑remove access or even fully remove external user accounts after package expires.

Exam angle:

• “External partners should request access to specific resources, require approval, auto‑expire access after 90 days, and automatically remove them if inactive.” → Use Entitlement management: catalogs + access packages + lifecycle settings.

2. Access reviews

Bullets: plan, create reviews for groups/apps, monitor findings, manage licenses, automate tasks, recurring reviews.

Plain explanation:

• Access Review = scheduled “Is this user still supposed to have this access?” check.

• You review:

  • Group membership.

  • App assignments.

  • Access packages.

  • PIM role assignments.

• Reviewers can be:

  • Managers, group owners, selected reviewers, or users themselves (self‑review).

Key knobs:

• One‑time vs recurring (e.g., every quarter).

• Auto‑apply results:

  • If no response → remove access, keep access, or decide per recommendation.

• Licensing: P2 needed for reviewers and many guest scenarios.

Exam angle:

• “Compliance rule: Teams membership must be re‑confirmed every 60 days, and removed automatically if no response.” → Use recurring access reviews with auto‑apply.

3. Privileged access with PIM

Bullets: privileged access strategy, PIM for Entra roles/Azure resources, assign roles, manage requests, audit, break‑glass.

Mental model:

• Normal state: people are eligible for a role, not active.

• When they need admin rights:

  • They activate role for X hours

  • Maybe need approval, MFA, justification, ticket number.

Important behavior details:

• Approvers have 24 hours to approve; not configurable.

• Best practice: at least two approvers per role.​

• PIM can send notifications and logs all activations for audit.

Break‑glass accounts:

• 2 cloud‑only Global Admins, not in PIM, excluded from CA + MFA where possible, stored safely for emergencies.

Exam angles:

• “Admin should not hold permanent Global Administrator; access only when needed with approval and auditing.” → Use PIM with eligible assignment, MFA, approvals, justification.

• “Global admin account used to configure PIM should remain usable even if CA breaks.” → That’s a break‑glass account excluded from strict CA/MFA.

4. Monitor and maintain Entra (logs, diagnostics, SIEM)

Bullets: analyze sign‑in logs, audit logs, diagnostic logs to Log Analytics/Sentinel/SIEM, workbooks, notifications.

Log types:

• Sign‑in logs:

  • Each sign‑in: who, where, app, device, CA result, risk info.

• Audit logs:

  • Changes to directory objects (users, groups, apps, policies).

• Provisioning logs:

  • SCIM and automated provisioning operations.

Diagnostics:

• Diagnostic settings let you stream logs to:

  • Log Analytics workspace (for KQL queries / workbooks).

  • Storage account (long‑term storage).

  • Event Hub (for 3rd‑party SIEM).

Workbooks & notifications:

• Built‑in workbooks visualize sign‑in risk, CA impact, etc.; you can set up alerts for certain events.

Exam angles:

• “Security team needs to run KQL queries on all sign‑in events and use Sentinel.” → Send sign‑in and audit logs to Log Analytics, then connect to Sentinel.

• “Third‑party SIEM must ingest Entra logs.” → Export via Event Hub or storage from diagnostic settings.

5. Global Secure Access (newer identity‑centric network security)

What it is:

• Global Secure Access (GSA) = Entra Internet Access + Entra Private Access.

• It’s Microsoft’s SSE solution:

  • Internet Access = outbound web protection (identity‑aware web gateway).

  • Private Access = identity‑aware access to internal apps (replace VPN).

Core bits you must know for exam:

• You deploy:

  • Client agent on devices.

  • Remote network connectors to route traffic.

• You use Universal Conditional Access policies to control traffic, same CA logic but now at network edge.

• Licensing: requires Entra P1/P2 plus GSA licensing or Entra Suite.

Exam angle:

• “Secure web browsing to all internet apps with Conditional Access rules, no VPN.” → Answer involves Entra Internet Access under Global Secure Access.

I will be adding additional topics, cheat sheets and question banks as well as I prepare for SC-300