LEARN. PRACTICE. GROW.Define the access the task requires
In a fictional project, an APS team needs to work on a resource group during a support window. Before configuring PIM, identify the person, role, scope, and permitted operation. Eligibility provides a path to request activation; it is not permanent active access. Define how request success will be recognized, who approves, how long activation lasts, and how access termination is tested. The ticket should describe the business operation justifying intervention. A screen showing an assignment does not demonstrate that the application accepts only intended actions. Record positive and negative acceptance checks.
Separate permission inheritance from policies
An Azure role granted at a higher scope can apply to lower resources. PIM activation policies follow a different rule: they are defined per role and resource, without automatic inheritance of subscription settings by a resource group. If two separate eligible assignments exist, the rehearsal must use the assignment and scope the person will actually activate. Configuring approval at subscription scope does not prove approval at group scope. Keep a table of scope, role, policy identity, approvers, and observed result. Repeat verification when the project creates a new access path or changes resource organization.
Inspect every grant path
Azure RBAC combines permissions from applicable assignments. Adding Reader on a resource group does not remove active Contributor inherited from the subscription. Likewise, ending PIM membership does not remove an independent direct assignment. In this lesson’s teaching model, Ana can export through the Operations group and through a direct grant. Removing only the group leaves the second path. The executable model represents explicit permissions and prefix scopes without reproducing denies, conditions, data actions, tokens, or the complete Azure engine. Use it to learn to look for residual paths; validate actual authorization in the specific service and scope.
Confirm what activation controls establish
Requiring a ticket reference in PIM does not automatically validate that number in a change tool. The process must demonstrate that the request exists, is approved, and covers the specific action. Similarly, no new prompt does not prove missing MFA: a session may already satisfy the requirement. Inspect policy and authentication evidence before concluding failure. For shift handover, record request, approval, activation time, and scope. A colleague should be able to connect these records with the authorized intervention without interpreting free text or a success screen as business approval. Keep the evidence sources separate.
Distinguish activation from subsequent use
When requiring authentication context, prepare and validate the applicable Conditional Access policy before associating it with PIM. The missing-policy fallback does not cover a Report-only, disabled, or user-excluding policy. Also, satisfying a device condition at activation does not guarantee that every later use of the role occurs on that device. The design needs policies appropriate to the access being protected. In a pilot, test activation and subsequent operation as separate moments using test accounts and prepared recovery. Record observed outcomes without promising enforcement outside configured scope. Protect administrators who can change these policies.
Manage Member and Owner as distinct roles
PIM for Groups can activate membership or ownership. Each group has its own Member and Owner policies; reviewing only Member approval leaves the other role unchecked. In our scenario, the owner manages group continuity while membership supports application access. These roles should not be treated as interchangeable. Also map who can change the group through other interfaces: PIM does not hide or eliminate other authorized administrative paths. During acceptance, test the required role and inspect effective state. Similar group names do not mean their policies or privileges are identical. Record group identity rather than relying on display names.
Plan departure of the last owner
Suppose A is an active owner and B has eligible ownership. B activates; A is then removed. B becomes the last active owner, and deactivation may not complete because Entra does not permit removal of the last owner. Documentation describes attempts for up to thirty days without guaranteeing removal if the condition persists. The departure plan should name an authorized active successor and confirm deactivation outcome. Waiting for the scheduled end is insufficient. Preserve group continuity and avoid deleting an object with dependencies merely to close an access issue quickly. Record who owns the follow-up.
Demonstrate revocation in the consumer
Membership can disappear from the directory while an application retains a session or cached decision. A direct grant can also remain valid. If the goal is to remove export access, check identity state, alternative paths, and a controlled functional attempt. Do not invent a universal TTL: behavior depends on the application. Handover should include removal evidence, test outcome, and session handling under the supported procedure. This lesson provides scenarios and local models; it does not execute PIM, change tenants, or establish revocation in a real service. An authorized isolated rehearsal remains necessary to validate the design.
Ana has export access through a group and a direct assignment. At 18:00 PIM membership ends. The test still succeeds through the direct path; removing membership alone does not meet the export-removal criterion.
Common pitfalls
Permission inheritance as policy inheritance; Reader as deny; ticket reference as validation; activation end as instant loss of every permission; last owner without a successor.
Related topics: Conditional Access · Access reviews · Support handover
Check policy at the correct scope, every grant path, and the consumer outcome before accepting activation or revocation.
Reference: PIM Azure resource role settings · SC-300 objectives effective 2026-04-27; product documentation reviewed 2026-10-01; 2026-10-28 English update compared separately