Lab 14 — Microsoft Graph PowerShell Command Chains (SC-300)
This lab is not about memorizing commands.
This lab trains you to:
- Read a business / security scenario
- Identify which identity objects must exist
- Determine what relationships are missing
- Select the correct sequence of command-line actions to establish those relationships
This directly mirrors how SC-300 questions are written.
The exam does NOT say:
“An application is missing permissions.”
Instead, it describes:
- a workload
- a security requirement
- an access failure
You must infer what is missing.
This lab works with four identity objects that SC-300 constantly blends together:
-
Tenant (Directory)
- Security boundary
- Hosts all identity objects
- Never “configured” directly in command chains
-
Application Object (App Registration)
- Global definition of an app
- Defines:
- requested permissions
- app roles
- supported OAuth flows
- Does NOT grant access
-
Service Principal (Enterprise Application)
- Tenant-local instance of the app
- Receives:
- permission grants
- consent
- assignments
- This is what actually runs in your tenant
-
Resource API (e.g., Microsoft Graph)
- Owns permission definitions (User.Read, Directory.Read.All, etc.)
- Your tenant cannot modify these permissions
- Apps can only request them
Permissions live on the RESOURCE, not on the app.
- Microsoft Graph defines
User.Read - Your app only REQUESTS
User.Read - Your tenant GRANTS
User.Readto the service principal
A custom application needs to:
- allow users to sign in
- read the signed-in user’s profile from Microsoft Graph
Users report:
- sign-in succeeds
- Graph calls fail with authorization errors
From the scenario:
- Application exists
- Service principal exists
- No permission grant exists
Missing:
- Delegated permission request on the application object
- Consent grant on the service principal
You must:
A. Modify the application object to request User.Read from Microsoft Graph
B. Grant consent on the service principal
- Locate the application
- Add delegated permission request (User.Read)
- Grant admin consent
Order matters.
If you attempt to grant consent:
- before the permission is requested
- the command fails
SC-300 tests this sequencing heavily.
- Require a signed-in user
- Act as the user
- Example: User.Read
- No user
- App acts as itself
- Requires explicit admin consent
- Example: Directory.Read.All
| Concept | What It Controls |
|---|---|
| Assignment | Who can sign in |
| Consent | What the app can do |
They are independent.
- Application object = definition
- Service principal = execution
- Resource API = permission authority
- Requests ≠ grants
- Consent is always applied to the service principal
- Command order matters more than command syntax
End of Lab 14
SC-300 tests reasoning, not syntax.
You must infer:
- which object is missing
- what relationship is missing
- which command fixes it
-
Tenant
- Security boundary
- Never granted permissions
-
Application Object
- Requests permissions
- Defines OAuth behavior
- Never receives consent
-
Service Principal
- Receives permission grants
- Enforces consent
- Can be assigned users
-
Resource API
- Defines permissions
- Immutable
- Permission exists on resource
- App requests permission
- Tenant grants permission to service principal
If question says:
“App cannot access Graph”
Think:
- Is permission missing?
- Is consent missing?
- Is it delegated or application?
- Delegated → user context
- Application → app identity only
- Assignment = who can sign in
- Consent = what can be accessed
If command:
- changes requested permissions → Application Object
- grants access → Service Principal
- reads state → GET
- creates relationship → NEW / ADD
If you know:
- which object
- which relationship
- which direction
The command choices become obvious.
End Summary