Recommend a Solution for Identity Governance — Lesson

This lesson is about Microsoft Entra ID Governance — the control plane that decides who gets what access, for how long, and under what conditions. We cover Privileged Identity Management (PIM), access reviews, Entitlement Management (access packages), Terms of Use, and the Entra P1 versus P2 licensing line. Identity governance is distinct from authentication (covered in LO4) and Azure RBAC role design (covered in LO6): governance is the lifecycle and oversight layer that sits on top of whatever identities and roles you already have.

AZ-305 frames governance as a design decision: given a requirement, which Entra feature satisfies it, and at what SKU?

Why This Matters

Standing privileged access is the single most exploited misconfiguration in enterprise cloud breaches. When an attacker phishes a user who holds a permanent Global Administrator role, the blast radius is the entire tenant. Governance features turn permanent, high-risk assignments into eligible assignments — access that exists on paper but must be activated, approved, and justified for a short window. The attacker inherits the user's eligibility, not their active rights.

Beyond security, auditors ask the same question every quarter: "Who had access to production in Q3, and who approved it?" Without access reviews and an audit trail, answering that takes a week of log archaeology. With access packages, it is one report. Licensing also matters for design: recommending PIM when the customer only has Entra P1 is a common exam failure mode, so this lesson treats the P1/P2 boundary as a first-class design constraint.

Prerequisites

• Entra ID basics — users, groups, roles, service principals. Self-check: What is the difference between a security group and a Microsoft 365 group?
• Azure RBAC — role assignments and scope hierarchy. Self-check: What happens to an RBAC assignment at resource-group scope when the subscription is moved?
• Conditional Access — signals, grant controls, session controls. Self-check: Which grant control forces a user to acknowledge a Terms of Use document?
• Tenant-level vs. Azure-resource roles — directory roles (e.g., User Administrator) are not Azure RBAC roles. Self-check: Can PIM govern both?
• Compliance vocabulary — SoD, least privilege, JIT, audit evidence. Self-check: Which control satisfies a SOX review of DB access every 90 days?

Learning Objectives

By the end of this lesson you will be able to:

1. Recommend PIM configurations (eligible assignment, activation settings, approval workflows) for a given privileged-access scenario.
2. Design access reviews — choose reviewers, cadence, auto-apply behaviour, and denial handling — to satisfy audit and compliance requirements.
3. Architect access packages in Entitlement Management that bundle cross-resource access for employees, contractors, or external partners with time-bounded lifecycles.
4. Evaluate when a Terms of Use policy is the correct answer versus a conditional-access grant control or a legal contract.
5. Recommend the minimum Entra licence (Free, P1, or P2) that satisfies a given governance requirement, and justify the incremental cost of P2.
6. Analyse a governance gap (e.g., standing admins, unreviewed guest access) and recommend a layered remediation using two or more Entra governance features.

Building Blocks

Identity governance — Analogy: an admissions office plus a records office for a university; it decides who is allowed on campus, for how long, and keeps proof of every decision. Formal definition: the set of policies, processes, and tools that ensure the right identities have the right access to the right resources at the right time, with an auditable record. Why it matters: governance is what turns access control into a defensible process auditors will accept.

Eligible assignment (PIM) — Analogy: a badge that is kept locked in a drawer at the reception desk; the employee may request it, but it is never worn by default. Formal definition: a role assignment that does not grant permissions until the principal activates it through PIM, usually with MFA, a time limit, and an optional approval workflow. Why it matters: eligibility replaces standing access — the default security posture for privileged roles.

Active assignment (PIM) — Analogy: a badge worn right now. Formal definition: a role assignment that is currently granting permissions, either because it is permanently active (discouraged) or because the principal activated an eligible assignment. Why it matters: the distinction between eligible and active is the core PIM vocabulary and the basis of every exam question on the topic.

Just-in-time (JIT) access — Analogy: the key to the server room is taped to the wall outside a locked door with a camera pointed at the door; you ring the bell, someone unlocks the door, and the clock starts ticking. Formal definition: access that is granted only when needed, for a finite duration, and revoked automatically when the duration expires. Why it matters: JIT is the operational pattern that PIM implements.

Access review — Analogy: the annual membership renewal for a club; if you do not return the form, your membership lapses. Formal definition: a time-bound campaign in which reviewers attest that a set of principals still need their access, with the option to auto-apply the results. Why it matters: access reviews are how organisations continuously trim dormant access, and they are the textbook audit control for role drift.

Access package — Analogy: a bundle of hotel amenities sold with the room — the room key, pool access, and gym access all expire when checkout happens. Formal definition: a resource bundle (groups, application role assignments, SharePoint sites) published in Entitlement Management that users can request, with approval, expiration, and access-review policies attached. Why it matters: access packages are the recommended governance unit for granting cross-resource access to both internal and external users.

Catalogue — Analogy: a printed menu of access packages; the manager can hand out menus without owning the kitchen. Formal definition: a container for access packages and their resources, owned by non-admin business users. Why it matters: catalogues let HR or finance own their own access-package portfolio without asking IT.

Terms of Use — Analogy: the digital version of the "I have read the handbook" signature at HR onboarding. Formal definition: a PDF-based consent document enforced by Conditional Access with a per-user attestation record. Why it matters: the only native Entra feature that stores per-user acceptance tied to a policy version.

Entra P1 — Analogy: the "business" tier of the licence menu. Formal definition: the per-user paid tier that includes Conditional Access, group-based licensing, self-service password reset with on-premises writeback, and dynamic groups — but not governance features. Why it matters: P1 is the cheapest path to Conditional Access, and many customers buy it and then discover they still cannot deploy PIM.

Entra P2 — Analogy: the "enterprise" tier of the licence menu. Formal definition: the per-user paid tier that adds Privileged Identity Management, Access Reviews, Entitlement Management, and Identity Protection on top of everything in P1. Why it matters: every feature in this lesson except Terms of Use sits behind the P2 licence wall.

Deep Dive

Identity governance in Azure is built from four pillars: PIM for privileged-role lifecycles, access reviews for recurring attestation, Entitlement Management for cross-resource bundling, and Terms of Use for compliance acknowledgement. Each maps to a specific audit control, and each is gated by a specific licence tier.

Privileged Identity Management (PIM)

PIM converts permanent role assignments into eligible assignments governed by activation policies. When a user wants to use the role, they open the PIM portal, select the role, enter a justification, optionally satisfy MFA and approval, and activate the role for a duration not exceeding the configured maximum (default 8 hours, cap 24 hours).

PIM covers three assignment targets, each with its own onboarding model and audit channel:

Activation policies control the behaviour of every role:

[!IMPORTANT] PIM does not reduce the number of role assignments — it changes the state from active to eligible. A user who was formerly a permanent Global Administrator is still a Global Administrator; they just have to click "Activate" and satisfy the policy to use the role. Design reviews often mistake PIM for a least-privilege tool; it is a JIT tool on top of whatever role set you already have.

PIM emits two signals worth wiring to your SIEM: activation events (who activated which role, when, why) and alerts (too-many active Global Admins, role activations outside normal hours, users activating rarely-used roles). Both appear in the Entra audit log and can be streamed via a Diagnostic Setting to a Log Analytics workspace.

PIM for Azure resources requires a separate onboarding step per subscription or management group. The Privileged Role Administrator enables PIM at a chosen scope; existing active role assignments remain in place but can be converted to eligible one at a time.

[!TIP] Onboard PIM at the management group scope rather than per-subscription — a single onboarding cascades.

Access Reviews

An access review is a campaign with four knobs: scope (which group, which role, or which access package), reviewers (self, manager, group owners, or named users), schedule (one-time or recurring — monthly, quarterly, annually), and auto-apply behaviour (what happens when the reviewer denies access or does not respond).

Typical review targets and their design fit:

[!NOTE] The "reviewer does not respond" outcome is a separate setting from the "reviewer denies" outcome. Many teams enable auto-apply on denial but leave "if not reviewed" set to "take no action" — which means a reviewer on holiday freezes the campaign.

For a quarterly admin-role review, the design choice is self-review vs. named reviewer. Self-review is cheaper (each admin attests to their own need), but auditors prefer a named reviewer because self-review invites the well-known "I'll just keep my access" bias.

Access reviews operate over state captured at review start: a user granted a role mid-cycle is not reviewed until the next cycle.

Entitlement Management and Access Packages

Entitlement Management is the piece most engineers meet last because it looks like "yet another group management tool" — until you realise it is the only native mechanism that lets a non-admin resource owner delegate cross-resource, time-bounded, approval-gated access to both employees and external partners, with zero help-desk tickets.

The hierarchy is:

Catalogue → Access package → Resource roles (group memberships, app roles, SharePoint site roles)

A catalogue is owned by one or more named users and scoped to a specific business context (e.g., "Finance Department"). Catalogue owners can publish access packages without holding any Entra directory role. Inside a catalogue, each access package declares:

1. Which resources it grants (groups, apps, SharePoint sites).
2. Who can request it (internal users, specific directory users, external partners, anyone on the internet via the portal link).
3. The approval workflow (no approval, single approver, two-stage, manager-then-owner).
4. The lifecycle (fixed expiry, access-review-linked, no expiry).
5. The access-review schedule for assigned users.

[!TIP] For external partners, the "Connected organisations" feature maps a partner domain (e.g., contoso-partner.com) to a pseudo-directory of users. Users from a connected organisation appear in access-package "who can request" pickers by organisation, not individual user, which is the correct design for B2B scenarios.

Every access-package assignment carries a user-visible expiration date. When that date arrives, the assignment is revoked and the resource roles are removed. Coupled with an access review mid-lifecycle, this is the textbook answer to "how do I give this contractor access to three SharePoint sites, one Azure DevOps project, and a Teams channel for the next 90 days, revocable automatically?"

Terms of Use and Governance Policies

Terms of Use (ToU) is the smallest governance feature and the one most often misused. It is a Conditional Access grant control that forces a user to open a PDF and click "I accept" before the sign-in completes. Entra records the per-user acceptance (user, ToU version, timestamp, IP) in an auditable log.

ToU is the correct answer when the control objective is: "We need to prove this user acknowledged policy X on this date." It is not a substitute for a signed legal contract and not a replacement for Conditional Access grant controls like MFA or compliant device.

Typical ToU deployments:

• Annual acceptable-use policy — all users, expires 365 days after acceptance, re-prompts next sign-in after expiry.
• Guest-user data handling — external users only, one-time acceptance, required before first access to a SharePoint site.
• Per-application ToU — for a specific SaaS app, ToU enforced by the Conditional Access policy that targets only that app.

[!WARNING] Terms of Use does not enforce policy behaviour — it only collects the click-through record. If you need to restrict data export after acceptance, combine ToU with a Conditional Access session control (e.g., app-enforced restrictions) or a DLP policy.

ToU sits on top of Entra P1 (because it relies on Conditional Access), unlike most other governance features which require P2.

Licensing — Entra P1 vs P2

Every question in the exam about governance features ends with an implicit licensing check. Memorise this line:

Licences are per-user and per-feature-user. PIM requires a P2 licence only for users acting on it: the approver, the user activating, and the user whose access is reviewed. A tenant can run 90% of users on Entra Free or P1 and buy P2 only for the 200 privileged users — a common design for cost optimisation.

[!IMPORTANT] Microsoft occasionally bundles P1 and P2 into Microsoft 365 E3 and E5 (respectively). Always verify against the current Microsoft 365 plan comparison rather than quoting bundles from memory — the bundling has changed three times in five years.

Worked Examples

Easy — Standing Global Administrators

Problem. Contoso has 6 permanent Global Administrator assignments held by the IT Operations team. The CISO wants zero standing Global Administrators. What minimum licence and configuration satisfies the requirement?

Step 1 — Identify the feature. Zero standing access means JIT. JIT for Entra roles is PIM.

Step 2 — Identify the licence. PIM requires Entra P2 per user who holds the eligible assignment.

Step 3 — Configuration steps:

1. Assign Entra P2 licences to the 6 IT Operations users.
2. Convert each existing active Global Administrator assignment to eligible via the PIM blade.
3. Configure the activation policy: max duration 4 hours, require MFA, require justification, require approval, approvers = a 2-person security team.
4. Run a quarterly access review over the 6 eligible assignments.

Recommendation. 6 P2 licences, PIM configured as above. Monthly cost assuming $$9$ per user = $$54$.

[!NOTE] The exam sometimes offers "assign P1 and use Conditional Access" as a distractor. Conditional Access can require MFA on role use, but it cannot convert a permanent assignment to eligible. Only PIM does that. P1 is not sufficient.

Medium — Quarterly review of external contractor access

Problem. Fabrikam has 45 external contractors from 3 partner firms who each need access to a SharePoint site, a Teams channel, and an Entra security group for the duration of their engagement. Engagements average 120 days. Auditors require a quarterly sign-off. How do you design it?

Step 1 — Eliminate bad answers.

• Individual guest invites + direct SharePoint sharing: unmanageable; no time-bound expiry; no consolidated review.
• A security group per partner firm, manually reviewed: brittle; revocation requires removing from all downstream resources individually.

Step 2 — Choose the right feature. We need (a) cross-resource bundling, (b) time-bounded assignment, (c) periodic review, (d) delegation to business owners. This is Entitlement Management.

Step 3 — Design:

1. Create one catalogue per partner firm owned by the partner's sponsor manager.
2. Create one access package per engagement type (e.g., "Fabrikam Manufacturing Audit — 120 days").
3. Configure "Connected organisations" for each partner's domain, so requests are scoped to their users only.
4. Requestor policy: requesting user must be from the connected org; approver = internal sponsor.
5. Lifecycle: expiration = 120 days.
6. Attach a quarterly access review with the sponsor as reviewer and auto-remove on denial.

Step 4 — Licensing. Assign Entra P2 to the sponsors and to any internal catalogue owners. External users do not consume internal P2 licences — they fall under the B2B collaboration monthly-active-users model.

Recommendation. Entitlement Management catalogue per firm; access packages per engagement type; connected-organisation scoping; quarterly review with auto-remove.

[!TIP] The "cross-resource bundling" clue is the signal for Entitlement Management. Whenever a question mentions granting a combination of groups plus SharePoint plus Teams plus an app role to one set of users, the answer is an access package — not a Conditional Access policy, not a dynamic group.

Hard — Segregation of duties for production database access

Problem. Tailwind Traders runs a regulated workload. Compliance requires: (a) no developer may simultaneously hold write access to production and production audit-log read access, (b) all privileged database operations are approved by a second person, (c) quarterly evidence must be produced listing every production access granted, by whom, and who approved it. Design the governance layer.

Step 1 — Decompose the requirements.

• Requirement (a): SoD. PIM supports incompatible-role detection as a policy, but it is a tenant-wide setting and works on Entra directory roles. For Azure RBAC roles, the SoD control belongs inside access-package policies (an access package can forbid simultaneous assignment with another named package).
• Requirement (b): approval on activation. Classic PIM role activation with approval.
• Requirement (c): audit evidence. Access reviews + PIM audit log export.

Step 2 — Architect.

1. Create two Azure RBAC custom roles: Prod DB Writer (write on Azure SQL) and Prod Audit Reader (read on the audit Log Analytics workspace).
2. Onboard the production subscription into PIM for Azure resources.
3. Create two access packages — one per role — in an Entitlement Management catalogue. Configure the "incompatible access packages" setting so that holding one blocks requesting the other.
4. Activation: PIM policy requires MFA, justification, ticket number, and approval by the on-call security engineer.
5. Access review: quarterly, reviewer = security engineering manager, auto-remove on denial.
6. Diagnostic settings on the subscription stream PIM activations to Log Analytics for KQL-based evidence.

Step 3 — Evidence. Run a scheduled KQL query against the PIM activation log, summarise per-role activations and approvers per quarter, and feed the output to the auditor's SharePoint site via an access package.

[!WARNING] The SoD enforcement in access packages is request-time, not assignment-time. If a user already holds role A and is manually assigned role B outside the access-package flow (e.g., a Global Admin adds them directly to the RBAC role), the SoD check does not fire. The defensive posture is: block direct RBAC assignments via Azure Policy and require all privileged access to flow through the access-package request path.

Visual Explanations

Figure 1 — Decision tree: which governance feature for which requirement?

Caption. Start from the control objective, not the feature. PIM and access reviews are complementary — PIM governs activation, reviews govern continued need. The requirement phrase "cross-resource bundle" is the single strongest signal for Entitlement Management.

Figure 2 — PIM activation lifecycle (left-to-right sequence as a graph LR)

Caption. Every transition is recorded in the Entra audit log. Approvers can be users, groups (first-respond-wins), or nested policies — named groups scale better than individual approvers.

Figure 3 — Entitlement Management object model (TikZ)

Caption. A catalogue is the delegation boundary — catalogue owners do not need global admin. The access-package is the request/approval unit. Resources can appear in multiple access packages; the same group can be granted via different packages with different policies.

Table — Feature-to-requirement mapping (quick reference)

Common Mistakes

❌ Myth: PIM reduces the number of admins in a tenant.

✅ Reality: PIM reduces the number of active admins at any given moment. The count of assignments is unchanged; only their state (eligible vs. active) differs.

Why it's tricky: Candidates conflate JIT with least privilege. JIT is a temporal control; least privilege is a permission-scope control. You still need to size the role set correctly.

❌ Myth: An access review enforced on a group will automatically remove users who fail the review from downstream apps.

✅ Reality: The review removes the user from the group. Downstream access disappears only if it was inherited through group membership. If the user has a direct app assignment outside the group, the review will not touch it.

Why it's tricky: Reviews operate at the scope you point them at — no further. Mapping from group membership to application access must be set up through group-based licensing or group-assignable app roles.

❌ Myth: Terms of Use is a binding legal signature.

✅ Reality: ToU collects a click-through attestation with a timestamp. It has evidentiary value for compliance audits but most legal teams still require a separately-executed contract for contractor onboarding or EULA acceptance of licensed software.

Why it's tricky: The UX looks like a signature page, which sets expectation. Treat ToU as "compliance evidence", not "legal signature".

❌ Myth: I need P2 for every user in the tenant to use PIM.

✅ Reality: P2 is required only for users who use the feature — the eligible-role holder, the approver, and the reviewed principal. A $10{,}000$-user tenant can buy P2 for 200 admins and P1 for the rest.

Why it's tricky: Per-user licensing rules differ per feature. Identity Protection risk-based Conditional Access requires P2 for every user whose sign-in is risk-evaluated, which is often the whole tenant — a subtle distinction.

❌ Myth: Entitlement Management is just another name for "dynamic groups with approvals".

✅ Reality: Dynamic groups compute membership from attributes; they have no approval, no expiry, no cross-resource bundling, and no delegated catalogue ownership. Access packages are a request/approval/lifecycle model. The two features solve different problems; access packages can contain dynamic groups, but not vice versa.

Why it's tricky: Both features can result in a user being added to a group. The mechanism, governance trail, and licensing differ entirely.

Practice Exercises

Exercise 1 🟢 Easy — A customer has 4 users with permanent User Administrator role. They want zero standing assignments and want the ability to audit every role use. What licence and feature do you recommend?

▶💡 Hint

"Zero standing" + "audit every use" maps to a specific lifecycle mechanism.

▶✅ Solution

Entra P2 for the 4 users; convert their User Administrator assignments to eligible in PIM. Configure the activation policy to require MFA + justification; enable email notifications on activation to the security team. The Entra audit log captures every activation event.

Exercise 2 🟢 Easy — The CISO wants every user in the tenant to accept a data handling policy once per year, re-prompted on the annual anniversary. What feature satisfies the requirement, and what is the minimum licence?

▶💡 Hint

Annual acceptance with per-user timestamp is a classic use case for a Conditional Access grant control.

▶✅ Solution

Terms of Use bound to a Conditional Access policy that targets "All users / All cloud apps". Set "Expire consents" = 365 days and "Require users to re-accept every" = 1 year. Minimum licence: Entra P1 (because it requires Conditional Access).

Exercise 3 🟡 Medium — An organisation has 300 contractors who each need: (a) a security group membership, (b) an app role in a line-of-business SaaS app, (c) read access to one SharePoint site. Engagements last 6 months. A sponsor from the hiring team should approve; IT should not be in the approval chain. Design.

▶💡 Hint

The cross-resource bundling + business-owner approval + fixed expiry is a strong signal.

▶✅ Solution

Use an Entitlement Management access package in a catalogue owned by the hiring team. Package resources: the security group (member role), the SaaS app (app role), the SharePoint site (visitor role). Approval policy: single-stage approval by the user's manager (or sponsor). Lifecycle: 180-day expiration. Attach a 90-day access review midway. The hiring team catalogue owner does not need IT admin privileges. Assign Entra P2 to the catalogue owner, sponsor managers, and contractor accounts.

Exercise 4 🟡 Medium — A compliance team requires a quarterly access review of all external (guest) users in the tenant. If a guest does not respond to the review, they must be blocked from signing in and deleted after 30 days. Design.

▶💡 Hint

Guest user reviews have a built-in block-then-delete lifecycle distinct from the standard recommend/remove flow.

▶✅ Solution

Create a recurring quarterly access review targeting "Guest users" at the tenant level. Reviewer = each guest's inviter (sponsor). Enable "Reviewers decide if users still need access". Set the "If not reviewed" action to "Deny". Set the post-review behaviour to "Block users from signing in for 30 days then remove users from the tenant". Auto-apply decisions = on. Requires Entra P2 for guest reviews.

Exercise 5 🔴 Hard — Tier-0 (domain admin equivalent) role activations must require two-person approval, must complete within 1 hour, and must fail if the approver is the same person as the requester. What is the exact PIM configuration?

▶💡 Hint

Think about approver sets and the built-in "approver cannot be the same user" guardrail.

▶✅ Solution

PIM activation policy for the Tier-0 role (e.g., Global Administrator): Maximum duration = 1 hour. Require MFA = on. Require justification = on. Require ticket number = on. Require approval = on. Approver = a named security group (not individual users). PIM automatically excludes the activating user from the approver pool even if they are a member of the approver group (built-in separation-of-duty guard). Activation email goes to the security group DL; first approver to respond wins.

Exercise 6 🔴 Hard — Production and audit-log write access must be mutually exclusive for any user. The design must prevent a malicious admin who holds Global Admin from assigning both roles directly. Describe the control layers.

▶💡 Hint

Access-package incompatibility handles the request path; another Azure-wide control is needed for the direct-assignment path.

▶✅ Solution

Layer 1: All privileged role assignments flow through Entitlement Management access packages. The "Prod Writer" and "Audit Reader" access packages are declared mutually incompatible. Layer 2: Azure Policy (at management-group scope) with deny effect on direct roleAssignments write operations outside the PIM/Entitlement Management service principals. Layer 3: A Conditional Access policy requiring a privileged-access workstation (PAW) for the PIM portal. Layer 4: Alerts on any direct role assignment bypassing the access-package flow, streamed from the activity log to a SIEM.

Exercise 7 🟡 Medium — A developer claims PIM is "slowing them down" and asks to be re-granted permanent Contributor on a dev subscription. How do you respond, and what is the correct configuration?

▶💡 Hint

PIM activation policies can be tuned per role and per scope.

▶✅ Solution

Tune the activation policy on the dev subscription: max duration 10 hours (covers a full workday), no approval required, no ticket required, MFA still required. The developer activates once at the start of the day and remains active until the policy expires. The audit trail is preserved; the speed complaint is removed without creating standing access. If activation is still too slow, consider a PIM-eligible group membership with auto-renewal via access review — but keep the JIT pattern.

Exercise 8 🔴 Hard — You are asked to produce evidence, for a SOC 2 audit, of every production Azure role activation in the last 12 months, grouped by user and role, with approval records. Describe the pipeline.

▶💡 Hint

PIM logs flow through the Entra audit log; long retention needs an export destination.

▶✅ Solution

(1) Configure a Diagnostic Setting on the tenant to export AuditLogs (category) to a Log Analytics workspace in a dedicated audit-evidence subscription. (2) Retention on the workspace = 2 years (exceeds the 12-month requirement). (3) Enable archive tier for cost optimisation beyond 90 days. (4) Run a saved KQL query (shown earlier in this lesson) that summarises activations by role and user, filters to the 12-month window, and joins approval events from the RoleManagement operation names. (5) Schedule the query into a workbook and pin to an Azure Dashboard shared with auditors through an access package. (6) Retain the workspace's immutable diagnostic export for the full audit period.

Summary & Concept Map

• Governance = lifecycle + oversight on top of existing identities and roles. It is not a replacement for RBAC design; it is the JIT, approval, attestation, and audit layer sitting above it.
• PIM converts permanent assignments to eligible, activated JIT with MFA, justification, and optional approval. Works on Entra roles, Azure roles, and groups. Requires P2 per acting user.
• Access Reviews provide periodic attestation for group membership, roles, and access-package assignments; configure denial behaviour and "no response" behaviour independently; also P2.
• Entitlement Management bundles cross-resource access into access packages with approval, expiry, and review policies, delegable to non-admin catalogue owners; ideal for external partners via connected organisations; P2.
• Terms of Use captures per-user click-through acceptance; works with P1 because it piggybacks on Conditional Access.
• Licensing boundary is the single most-tested design constraint — memorise the P1-only versus P2-required features and verify counts against actual usage, not tenant size.
• The incompatible-roles pattern needs both access-package SoD settings and an Azure Policy guard against out-of-band role assignments; one layer is not enough.

Caption. Governance features form a pipeline: Entitlement Management assigns access; PIM controls activation of the more sensitive roles inside that access; access reviews close the loop by periodically asking "is this still needed?". Audit is the cross-cutting output feeding SIEM and compliance reporting.