1. PIM – Eligible vs Active Assignments

  • Eligible — User can activate the role but doesn't hold it permanently. Requires explicit activation (just-in-time).
  • Active — Role is always assigned; no activation needed. Use sparingly (service accounts, break-glass).
  • Time-bound — Both eligible and active assignments can have start/end dates for contractors or projects.

Design principle: Default to eligible assignments with short activation windows (1–8 hours) to minimize standing privilege.

2. PIM Activation Workflow

  • Approval workflows — Configure per-role; require one or more approvers from a designated group.
  • Notifications — Email alerts on activation, expiry, and denied requests.
  • Access reviews — Periodic recertification of eligible assignments (monthly/quarterly).

3. Conditional Access Policy Design

  • Named Locations — Define trusted IP ranges / countries. Use as grant or block conditions.
  • Device Compliance — Require Intune-compliant or Hybrid Azure AD Joined devices for sensitive apps.
  • Sign-in Risk — Identity Protection calculates real-time risk (anonymous IP, atypical travel). Block or require MFA for medium/high risk.
  • User Risk — Cumulative risk score (leaked credentials). Force password change at high risk.
  • Session Controls — App-enforced restrictions, sign-in frequency, persistent browser sessions.

Policy layering: Start with a baseline (require MFA for all), then add stricter policies for privileged roles and sensitive apps.

4. CA Signal Sources

User / Group
All users, specific role groups
Require MFA
Cloud App
Office 365, Azure Management
Block legacy auth
Location
Outside trusted named locations
Block or require MFA
Device State
Not compliant / not registered
Require compliant device
Sign-in Risk
Medium or High (Identity Protection)
Require MFA + password change
Client App
Browser, mobile apps, desktop
App protection policy
Workload Identity
Service principal from untrusted IP
Block access

5. Workload Identity Conditional Access

  • Applies CA policies to service principals and managed identities — not just users.
  • Restrict service principals to specific named locations (e.g., only your CI/CD runner IPs).
  • Requires Workload Identities Premium license.
  • Useful for blocking compromised app credentials authenticating from unknown networks.

6. Break-Glass Accounts

  • At least two emergency access accounts excluded from ALL CA policies.
  • Cloud-only (no on-prem dependency), long complex passwords or FIDO2 keys stored in a safe.
  • Permanently assigned Global Admin — active (not eligible) to bypass PIM during outages.
  • Monitor with Azure Monitor alerts on sign-in activity for these accounts.

💼 Real-World Scenario

A financial services firm configures PIM for all privileged roles with 4-hour activation, mandatory justification, and approval by the security team. CA policies enforce compliant devices + MFA for Azure portal access. Workload identity CA restricts their deployment service principal to GitHub Actions runner IPs only. Two break-glass accounts are excluded from all policies and monitored via Sentinel alerts.

🎯 Exam Tip

AZ-305 loves scenarios combining PIM + CA. Remember: PIM can require a CA policy (MFA, compliant device) at activation time. Break-glass accounts must be excluded from CA and use active (not eligible) role assignments. Workload identity CA only supports location-based conditions today.

🧪 Knowledge Check