An automation account’s managed identity needs Contributor on a resource group so a nightly job can resize a scale set. Why should the security engineer avoid an eligible PIM assignment for that identity?
Select an answer to reveal the explanation.
Short Explanation
A managed identity is a robot—it cannot open the PIM portal, pass MFA, or type a business reason. Give the automation account an active Contributor assignment for that resource group, not an eligible hat it can never put on.
Full Explanation
PIM eligible Azure RBAC assignments assume a principal that can perform interactive or supported activation steps. Managed identities and service principals used by automation cannot complete typical PIM activation (MFA, justification, ticket, approval wait) the way a human can. For an automation account’s managed identity that needs Contributor on a resource group for a nightly scale-set resize, the security engineer should use an active (often time-bound if policy allows) assignment rather than an eligible PIM assignment that the runbook cannot activate.
Claiming managed identities activate eligible roles only through Azure Arc fails—that is not how PIM activation works for automation identities. Claiming eligible assignments auto-convert to active after the first runbook fails; no such conversion is the supported model. Claiming PIM eligible assignments exist only for Owner and User Access Administrator fails because PIM for Azure resources covers many Azure roles, but the activation model still presupposes an activator that can complete the workflow.
Exam caveat: prefer managed identity + least-privilege active Azure RBAC for unattended jobs; reserve eligible PIM for human operators. Operational check: assign active Contributor (scoped tightly) to the managed identity, run the nightly job, confirm resize succeeds without interactive activation, and alert on unexpected role changes to that identity.