SC-300: Identity and Access Administrator — PowerShell Prep

Exam facts

The SC-300 exam has 40–60 questions, a 120-minute time limit, and a passing score of 700 out of 1000. Most questions are multiple choice, case studies, and yes/no statements. Roughly a quarter of the exam is PowerShell: the rest is portal configuration and concepts. That means you cannot pass on PowerShell alone, but every PowerShell question is a question you can answer in seconds if you know the cmdlet and its required permission scope.

Almost every SC-300 PowerShell question hinges on one of three things: which cmdlet does the job, which permission scope it requires, and whether the feature lives on the v1.0 or beta Graph endpoint. This track drills all three.

Before you start: the Graph SDK, scopes, and a retired module

SC-300 is a Microsoft Graph exam. You connect with the Microsoft Graph PowerShell SDK, and every command starts with Mg. Before running anything below, install the SDK and connect with the scopes the task needs. Least privilege is itself an exam topic: never connect with more scopes than the task requires.

Install-Module Microsoft.Graph -Scope CurrentUser
Import-Module Microsoft.Graph
Connect-MgGraph -Scopes "User.ReadWrite.All", "Group.ReadWrite.All"
Get-MgContext

Get-MgContext shows who you signed in as and which scopes were granted. If a command later fails with an authorization error, check the context first: the usual cause is a missing scope, not a typo. Some identity features only exist on the beta endpoint, so switch profiles when a cmdlet or property is missing from v1.0.

Select-MgProfile -Name "beta"
Get-MgContext
Disconnect-MgGraph

Domain 1: Implement and manage user identities (20–25%)

This domain covers the full user and group lifecycle: creating, updating, and removing users, assigning licenses, managing group membership, inviting external guests, and managing devices. The exam tests both single-object operations and bulk patterns. Bulk onboarding from a CSV file is the single most representative task in this domain, and it combines three skills the exam loves: Import-Csv, a ForEach-Object loop, and New-MgUser with a password profile.

Two query techniques appear repeatedly. First, server-side filtering with -Filter using OData syntax, for example accountEnabled eq true. Second, advanced queries that require the -ConsistencyLevel eventual header together with -Search or $count. If a question asks you to search users by a property that normal filtering does not support, the answer almost always involves -ConsistencyLevel eventual. Group types matter too: a security group, a Microsoft 365 group, and a dynamic membership group are created with different parameters, and dynamic groups use a membership rule string such as (user.department -eq "Sales").

Connect-MgGraph -Scopes "User.ReadWrite.All", "Group.ReadWrite.All"
New-MgUser -DisplayName "Asha Verma" -UserPrincipalName "asha@contoso.com" `
  -MailNickname "asha" -AccountEnabled `
  -PasswordProfile @{ Password = "TempPass123!"; ForceChangePasswordNextSignIn = $true }
Get-MgUser -Filter "accountEnabled eq true" -Property DisplayName, UserPrincipalName, Department

Creating a user requires a password profile and a mail nickname; omitting either is the most common beginner error. The ForceChangePasswordNextSignIn flag is what makes a temporary password safe to hand out. For lookups, prefer -Filter over piping everything through Where-Object: server-side filtering returns fewer objects and is what the exam answer expects.

Import-Csv new-users.csv | ForEach-Object {
  New-MgUser -DisplayName $_.DisplayName -UserPrincipalName $_.UserPrincipalName `
    -MailNickname $_.MailNickname -AccountEnabled `
    -PasswordProfile @{ Password = $_.TempPassword; ForceChangePasswordNextSignIn = $true }
}
New-MgGroup -DisplayName "Sales Dynamic" -MailEnabled:$false -SecurityEnabled `
  -GroupTypes "DynamicMembership" `
  -MembershipRule '(user.department -eq "Sales")' -MembershipRuleProcessingState "On"
New-MgInvitation -InvitedUserEmailAddress "partner@fabrikam.com" -InviteRedirectUrl "https://myapplications.microsoft.com"

Exercise — bulk onboarding from CSV. Create a CSV with five users (DisplayName, UserPrincipalName, MailNickname, TempPassword). Import it and create all five accounts with forced password change at next sign-in. Then create a security group, add the five users as members, and verify membership with Get-MgGroupMember. Finally, invite one external guest and check the invitation status. If any creation fails, run Get-MgContext first and confirm the User.ReadWrite.All scope is present.

Domain 2: Implement authentication and access management (25–30%)

This is the largest exam domain, and the one most candidates underprepare. It covers multifactor authentication, self-service password reset, password protection, authentication methods, Conditional Access policies, and Identity Protection. Conditional Access alone is worth deep study: it is the control that ties users, devices, locations, applications, and risk signals together, and the exam tests policy construction, evaluation order, and exclusions in detail.

Two facts shape everything in this domain. First, Conditional Access policies are managed through the beta Graph endpoint, not v1.0 — so Select-MgProfile -Name "beta" is a prerequisite, and any answer that omits it is wrong. Second, every policy needs a break-glass account excluded from it. A policy that applies to "all users" with no exclusion can lock every administrator out of the tenant, and the exam tests that exclusion explicitly. Authentication methods are per-user objects: you register a phone method, an authenticator method, or a FIDO2 key for a specific user, and the tenant-level authentication methods policy controls which methods are available at all.

Select-MgProfile -Name "beta"
Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess", "Policy.Read.All"
$conditions = @{
  Users = @{ IncludeUsers = @("All"); ExcludeUsers = @("breakglass@contoso.com") }
  Applications = @{ IncludeApplications = @("All") }
  ClientAppTypes = @("browser", "mobileAppsAndDesktopClients")
}
$grantControls = @{ Operator = "OR"; BuiltInControls = @("mfa") }
New-MgIdentityConditionalAccessPolicy -DisplayName "Require MFA for all users" `
  -State "enabled" -Conditions $conditions -GrantControls $grantControls
Get-MgIdentityConditionalAccessPolicy

The policy above is the single most exam-representative lab on this page: MFA required for all users on all cloud apps, with a break-glass account excluded. Note the structure — conditions (who, what apps, what clients) are separate from grant controls (what is required). A policy in reportOnly state evaluates but does not enforce; the exam tests that distinction, so always check -State when troubleshooting a policy that "isn't working."

Connect-MgGraph -Scopes "UserAuthenticationMethod.ReadWrite.All"
Get-MgUserAuthenticationMethod -UserId "asha@contoso.com"
New-MgUserAuthenticationPhoneMethod -UserId "asha@contoso.com" `
  -PhoneNumber "+91 98765 43210" -PhoneType "mobile"
Get-MgRiskyUser -Filter "riskState eq 'atRisk'"

Exercise — Conditional Access end to end. Switch to the beta profile and create a policy that requires MFA for all users on all cloud apps, excluding your break-glass account. Verify it with Get-MgIdentityConditionalAccessPolicy and confirm its state is enabled, not reportOnly. Then register a phone authentication method for a test user, list the user's methods, and reset them to force re-registration. Finally, list at-risk users with Get-MgRiskyUser and explain what action each risk level requires.

Domain 3: Plan and implement workload identities (20–25%)

Workload identities are the non-human identities in a tenant: app registrations, service principals, managed identities, and the permission grants that connect them. The exam tests the full lifecycle — register an application, create its service principal, grant API permissions, create a client secret, and understand the difference between delegated permissions (a user signs in) and application permissions (the app acts alone). Admin consent is the gatekeeper: some permissions require an administrator to consent before any user or app can use them.

Managed identities deserve special attention because they remove the secret-management problem entirely. A system-assigned managed identity lives and dies with its Azure resource, while a user-assigned managed identity is a standalone resource that several workloads can share. The exam tests which type fits which scenario, and that managed identity authentication uses Azure AD tokens rather than stored credentials. Application Proxy is the smaller corner of this domain: publishing an on-premises application through Entra ID so remote users reach it without a VPN.

Connect-MgGraph -Scopes "Application.ReadWrite.All"
$app = New-MgApplication -DisplayName "Contoso Reporting API" -SignInAudience "AzureADMyOrg"
New-MgServicePrincipal -AppId $app.AppId
$secret = New-MgApplicationPassword -ApplicationId $app.Id -PasswordCredential @{
  DisplayName = "Reporting secret"; EndDateTime = (Get-Date).AddMonths(6)
}
Get-MgApplication -ApplicationId $app.Id
Get-MgServicePrincipal -Filter "appId eq '$($app.AppId)'"

Registering an app and creating its service principal are two separate steps — a common exam trap is assuming registration alone makes the app usable in the tenant. The client secret's expiry matters too: a secret that expires breaks the application, and the exam tests secret rotation as an operational task. Store secrets in Azure Key Vault, never in code or scripts.

Connect-MgGraph -Scopes "DelegatedPermissionGrant.ReadWrite.All", "Application.Read.All"
Get-MgOauth2PermissionGrant -Filter "clientId eq '00000003-0000-0000-c000-000000000000'"
Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $sp.Id

Exercise — app registration end to end. Register an application, create its service principal, and add a client secret with a six-month expiry. Grant one delegated API permission and record the admin-consent step — note that consent itself is a portal action, not a Graph cmdlet, and the exam tests knowing which steps have no cmdlet equivalent. Then audit permission grants: list OAuth2 grants for the Microsoft Graph service principal and identify any grant that exceeds least privilege.

Domain 4: Plan and automate identity governance (20–25%)

Governance answers the question "who should still have access?" Privileged Identity Management (PIM) makes privileged roles time-bound and approval-gated instead of permanently assigned. Entitlement management packages access into requestable bundles with approval workflows. Access reviews periodically ask managers or group owners to confirm that members still need access. Lifecycle workflows automate joiner, mover, and leaver tasks. Together these are the controls that prevent privilege creep — and the exam tests them as a system, not as isolated cmdlets.

The PIM distinction the exam tests most is eligible versus active. An eligible assignment means the user can activate the role; an active assignment means they have it right now. Activation is a separate request with a justification and a duration, and it is the activation request — not the assignment — that most candidates confuse. Access reviews run on a schedule against a scope (a group, an application, or a role) and produce decisions: approve, deny, or no response. Monitoring ties it together: sign-in logs and audit logs are the evidence that governance is working, and the exam expects you to query them with Graph.

Connect-MgGraph -Scopes "RoleManagement.ReadWrite.Directory", "RoleManagement.Read.Directory"
Get-MgRoleManagementDirectoryRoleEligibilitySchedule -Filter "principalId eq 'user-id-here'"
$params = @{
  RoleDefinitionId = "62e90394-69f5-4237-9190-012177145e10"
  PrincipalId = "user-id-here"
  DirectoryScopeId = "/"
  Action = "selfActivate"
  ScheduleInfo = @{ StartDateTime = (Get-Date).ToUniversalTime(); Expiration = @{ Type = "AfterDuration"; Duration = "PT4H" } }
  Justification = "Emergency access for incident response"
}
New-MgRoleManagementDirectoryRoleAssignmentScheduleRequest -BodyParameter $params
Get-MgRoleManagementDirectoryRoleAssignment -Filter "principalId eq 'user-id-here'"

The role definition ID above is Global Administrator. The activation request is what turns an eligible assignment into a four-hour active assignment with a recorded justification — that justification is auditable evidence, and the exam treats it as a required field, not an optional note. After activation, verify with the assignment list: if the assignment does not appear, the user was never eligible, and the fix is an eligibility schedule, not another activation request.

Connect-MgGraph -Scopes "AuditLog.Read.All", "IdentityRiskyUser.Read.All"
Get-MgAuditLogSignIn -Filter "status/errorCode ne 0" -Top 20
Get-MgRiskyUser -Filter "riskLevel eq 'high'"
Get-MgAuditLogDirectoryAudit -Filter "activityDisplayName eq 'Add member to group'"

Exercise — PIM activation and audit investigation. List the eligible role assignments for a test user and confirm whether Global Administrator is eligible or already active. Submit an activation request for four hours with a justification, then verify the active assignment. Next, pull the last 20 failed sign-ins, identify any user with a high risk level, and explain the remediation steps: confirm or dismiss the risky user, reset authentication methods, and require password change. Finally, query the directory audit log for group membership changes in the last 24 hours.

Study path and exam tips

Work the domains in this order: user identities first, because every later domain assumes you can create and query users and groups. Then authentication and access management, the largest domain — spend the most time on Conditional Access policy construction. Then workload identities, then governance. Budget roughly one week per domain if you are studying part-time, and finish with a full review week on the traps: beta versus v1.0, least-privilege scopes, break-glass exclusion, and eligible versus active.

Before booking, you should be able to do these without notes: connect with the right scopes, bulk-create users from CSV, build a Conditional Access policy requiring MFA with a break-glass exclusion, register an app and create its service principal, activate a PIM role with justification, and pull failed sign-ins from the audit log. If any of those requires looking up the cmdlet name, that is your next study session.

Cross-links: the Entra PowerShell track covers Graph connection, user queries, and lifecycle automation in lesson form, and the Microsoft Graph and Entra guide explains the Graph concepts behind these cmdlets. For the individual commands, use the command reference pages linked in the tables above, especially Get-MgUser, Get-MgGroup, and Connect-MgGraph.

Quick reference: all SC-300 cmdlets on this page