Skip to content

Part of my AI collaborative lab series for Microsoft Identity and Access Administration skill development and expertise pathway.

Notifications You must be signed in to change notification settings

Compcode1/lab-14-command-chains

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

2 Commits
 
 

Repository files navigation

Lab 14 — Microsoft Graph PowerShell Command Chains (SC-300)

Lab 14 — Command-Chain Reasoning for Microsoft Entra ID (SC-300)

Purpose of This Lab

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.


Identity Objects In Scope

This lab works with four identity objects that SC-300 constantly blends together:

  1. Tenant (Directory)

    • Security boundary
    • Hosts all identity objects
    • Never “configured” directly in command chains
  2. Application Object (App Registration)

    • Global definition of an app
    • Defines:
      • requested permissions
      • app roles
      • supported OAuth flows
    • Does NOT grant access
  3. Service Principal (Enterprise Application)

    • Tenant-local instance of the app
    • Receives:
      • permission grants
      • consent
      • assignments
    • This is what actually runs in your tenant
  4. 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

Critical Exam Rule

Permissions live on the RESOURCE, not on the app.

  • Microsoft Graph defines User.Read
  • Your app only REQUESTS User.Read
  • Your tenant GRANTS User.Read to the service principal

Scenario 1 — Delegated Access Failure

Business Scenario

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

Step 1 — Identify What Exists

From the scenario:

  • Application exists
  • Service principal exists
  • No permission grant exists

Step 2 — Identify the Missing Relationship

Missing:

  • Delegated permission request on the application object
  • Consent grant on the service principal

Step 3 — Correct Command-Chain Logic (Exam Thinking)

You must: A. Modify the application object to request User.Read from Microsoft Graph
B. Grant consent on the service principal


Step 4 — Conceptual Command Chain (Exam Style)

  1. Locate the application
  2. Add delegated permission request (User.Read)
  3. Grant admin consent

Order matters.


Why Order Matters

If you attempt to grant consent:

  • before the permission is requested
  • the command fails

SC-300 tests this sequencing heavily.


Delegated vs Application Permissions (Exam Critical)

Delegated Permissions

  • Require a signed-in user
  • Act as the user
  • Example: User.Read

Application Permissions

  • No user
  • App acts as itself
  • Requires explicit admin consent
  • Example: Directory.Read.All

Assignment vs Consent (Common Exam Trap)

Concept What It Controls
Assignment Who can sign in
Consent What the app can do

They are independent.


Key Exam Takeaways

  • 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

Lab 14 — SC-300 Command-Chain Summary

Core Insight

SC-300 tests reasoning, not syntax.

You must infer:

  • which object is missing
  • what relationship is missing
  • which command fixes it

Identity Object Responsibilities

  • 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 Flow (Always This Order)

  1. Permission exists on resource
  2. App requests permission
  3. Tenant grants permission to service principal

Exam Pattern

If question says:

“App cannot access Graph”

Think:

  • Is permission missing?
  • Is consent missing?
  • Is it delegated or application?

Delegated vs Application

  • Delegated → user context
  • Application → app identity only

Assignment vs Consent

  • Assignment = who can sign in
  • Consent = what can be accessed

Command-Chain Heuristic

If command:

  • changes requested permissions → Application Object
  • grants access → Service Principal
  • reads state → GET
  • creates relationship → NEW / ADD

Final Rule

If you know:

  • which object
  • which relationship
  • which direction

The command choices become obvious.

End Summary

About

Part of my AI collaborative lab series for Microsoft Identity and Access Administration skill development and expertise pathway.

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published