Plan and Automate Identity Governance practice questions

Privileged Identity Management (PIM) for Azure Resources.

Why wrong: PIM is designed for managing high-privilege administrative roles rather than standard user access to productivity resources like SharePoint or Teams. While it provides time-bound access, it does not offer the catalog-based self-service request workflow that external vendors need for basic collaboration and resource consumption within a project scope.

Manual Guest User invitation via the Microsoft Entra admin center.

Why wrong: Manual invitations do not provide a scalable way to manage the lifecycle of many users or provide self-service request capabilities. This method requires administrative effort for every user and lacks the automated expiration and governance controls found in Entitlement Management, making it difficult to track when access should be revoked.

Conditional Access policies with Session Control.

Why wrong: Conditional Access focuses on the conditions under which a user can sign in, such as location or device compliance, rather than the provisioning of resource access. While it can enforce MFA for guest users, it does not manage the assignment of resources or the automated lifecycle of project-based access.

Require Azure Backup for all associated resources.

Why wrong: Azure Backup is a service for data protection and recovery and is not a setting within the PIM role activation workflow. PIM focuses on identity governance and access control rather than data redundancy or backup schedules for the resources that the administrator might manage after they have gained access.

Require a Windows 11 Enterprise license.

Why wrong: Licensing requirements for the client operating system are not part of the PIM role activation settings. While certain features in Microsoft Entra require specific licenses, the activation of a role itself is governed by identity policies rather than the specific version of Windows running on the administrator's local workstation.

Require the user to be in a specific physical location.

Why wrong: While Conditional Access can enforce location-based restrictions, PIM role activation settings themselves do not natively include a 'physical location' requirement. PIM relies on MFA, justification, and approval workflows. Location-based security is managed separately through the broader Conditional Access framework which applies during the initial sign-in phase.

Seven days before the user's hire date.

Why wrong: The 'equalTo' operator indicates that the workflow runs on the exact date found in the attribute. To run seven days before, the configuration would need a 'timeBasedAttributeOperator' set to 'offsetBefore' with a value of seven days. This allows for pre-boarding tasks, but it is not what is currently configured.

Immediately when the user account is created in Entra ID.

Why wrong: Account creation is a separate event from the hire date attribute trigger. While many workflows are triggered by account creation, this specific JSON is explicitly configured to watch the 'employeeHireDate' attribute. Therefore, the account could exist for days or weeks before this specific workflow logic is actually triggered.

Every time the user's department is updated to 'Marketing'.

Why wrong: The workflow is triggered by a time-based attribute (hire date), not a change in the department attribute. While workflows can be scoped to specific departments using execution conditions, the primary trigger here is the date, not a change in the user's job role or organizational unit within the directory.

Set 'Upon non-response' to 'Remove access' for the entire review.

Why wrong: Setting 'Remove access' globally would affect every member of the group equally. If a reviewer fails to respond, internal employees would lose their access alongside guest users. This does not meet the requirement of keeping internal users' access intact while specifically targeting the removal of guest user access upon non-response.

Enable 'Decision helpers' and set 'Take recommendations'.

Why wrong: Decision helpers provide recommendations based on user activity, such as the last sign-in date. While helpful, 'Take recommendations' will apply whatever action the system suggests (which might be 'Approve' if the user is active). This does not guarantee the removal of guest access specifically in the event of a reviewer's total non-response.

Set 'Upon non-response' to 'Approve access' and use a Logic App.

Why wrong: Setting 'Approve access' would maintain access for everyone, including guests, which contradicts the goal. While a Logic App could theoretically trigger on review completion, it introduces unnecessary complexity when the built-in scoping and non-response features of Access Reviews can achieve the desired outcome more natively and reliably.

Azure Key Vault secrets.

Why wrong: Azure Key Vault secrets are managed through Azure RBAC or Key Vault access policies and are not a supported resource type within Entitlement Management catalogs. Entitlement Management focuses on user-facing resources like groups and apps rather than individual secrets or connection strings used by developers or services.

Individual user mailboxes.

Why wrong: Entitlement Management governs access to shared resources and groups, but it does not manage individual user mailboxes. Personal mailbox access is typically managed through Exchange Online permissions or delegation and is not a resource type that can be added to a catalog for distribution via access packages.

Privileged Identity Management (PIM).

Why wrong: PIM is used for managing time-bound, elevated administrative roles. While it can require justification for role activation, it is not designed to present general organizational policies or legal terms to the entire user base as a condition for accessing standard applications like Outlook or Teams.

Azure Information Protection (AIP) labels.

Why wrong: AIP labels are used to classify and protect documents and emails by applying encryption or visual markings. While AIP helps with data governance, it does not provide a mechanism for user-level policy acknowledgment or consent tracking for application access within the Microsoft Entra ID environment.

Access Reviews.

Why wrong: Access Reviews are used to verify that users still need access to groups or applications. While they are a governance tool, they do not present a document for the user to read and accept. Their purpose is for managers or owners to audit existing permissions rather than enforcing policy consent.

Delete user account.

Why wrong: While deleting an account is part of a long-term cleanup, it is usually not the first step in a Leaver workflow. Disabling the account is preferred as it allows for data recovery or legal holds if needed. Immediate deletion can lead to permanent data loss if not handled with caution.

Remove user from all SharePoint sites.

Why wrong: While removing access is important, disabling the account (Option A) effectively blocks access to all SharePoint sites at once. Individual removal from every site is less efficient and is usually handled indirectly through group membership removal or by the account being disabled, which blocks all authentication attempts.

Reset user password.

Why wrong: Resetting the password is an additional security measure, but it does not prevent the user from attempting to sign in if they somehow obtain the new password. Disabling the account is the authoritative way to stop access, making a password reset redundant in a standard automated offboarding workflow.

Catalog Owner.

Why wrong: A Catalog Owner has full control over the catalog, including the ability to add and remove resources and manage all access packages. Assigning this role would give the project lead too much permission, as they would be able to add any resource they want to the catalog, violating the requirement.

Access Package Assignment Manager.

Why wrong: The Access Package Assignment Manager role is more restricted than the Access Package Manager. It only allows the user to manage existing assignments and view requests; it does not grant the permissions necessary to create new access packages or modify the settings of existing ones.

User Administrator.

Why wrong: User Administrator is a broad Microsoft Entra directory role. While it allows for the management of users and groups, it is not a catalog-specific role within Entitlement Management. Using directory-level roles for catalog management lacks the granularity needed for delegated identity governance within specific business units.

The user is made eligible for the role indefinitely.

Why wrong: Eligibility is a different state than an active assignment. Furthermore, the 'expiration' type is 'afterDuration' set to four hours, which explicitly limits the timeframe of the assignment. Indefinite eligibility would not include a duration or a specific start time in this manner.

A request is created that requires approval from a second administrator.

Why wrong: The 'AdminAssign' action typically represents an administrative override or direct assignment that does not trigger the standard user-initiated activation workflow. If approval were required, the payload would usually involve a 'SelfActivate' action and the status of the resulting request would be 'PendingApproval'.

The user is permanently assigned to the role with no expiration.

Why wrong: The presence of the 'expiration' object with a 'duration' of 'PT4H' directly contradicts the idea of a permanent assignment. In PIM, assignments can be permanent, but this specific API call is explicitly configured to revoke the access automatically after the four-hour window has elapsed.

The review will automatically skip users without a manager.

Why wrong: Skipping users would create a compliance gap, as those users' access would never be verified. Access Reviews are designed to be comprehensive; therefore, the system requires a configuration to handle cases where the primary reviewer (the manager) cannot be identified in the directory.

The Global Administrator will receive all reviews for users without managers.

Why wrong: The system does not default to the Global Administrator for missing manager attributes. This would be inefficient and create a bottleneck. Instead, the administrator creating the review must explicitly define who should handle these cases by setting a fallback reviewer within the review's configuration.

Users without a manager will be prompted to review their own access.

Why wrong: While 'Self-review' is an option for Access Reviews, it is a distinct choice from 'Manager'. If the review is set to 'Manager', the system will not automatically switch to 'Self-review' for a subset of users; it requires a designated fallback reviewer to maintain the intended governance structure.

Enable the 'Allow All Users' setting in the External Identities provider.

Why wrong: Enabling 'Allow All Users' at the provider level is too broad and does not align with the requirement of targeting specific partners. It would allow any external user from any domain to potentially interact with your directory, which bypasses the granular control offered by Entitlement Management's connected organizations.

Assign the 'Guest Inviter' role to the users in the external organizations.

Why wrong: The 'Guest Inviter' role is for internal users who need to invite guests. It is not something you assign to external users. External users do not need this role to request access through an access package; they only need a policy that grants them the permission to request it.

Set the access package visibility to 'Public'.

Why wrong: There is no 'Public' visibility setting in Entitlement Management that allows anyone on the internet to request a package. Visibility is controlled by policies. A policy must be scoped to either internal users, specific external organizations, or all external users (which is still restricted to authenticated identities).

Assign the 'Global Administrator' role to the requesting user permanently.

Why wrong: Assigning a permanent Global Administrator role violates the principle of least privilege and bypasses all governance controls. This is an insecure practice that eliminates the benefits of PIM, leaving the environment vulnerable to credential theft or accidental administrative errors.

Set the activation duration to 24 hours to reduce the number of requests.

Why wrong: Increasing the activation duration does not solve the problem of an unavailable approver; it only reduces the frequency of requests. Furthermore, longer activation windows increase the 'blast radius' if an account is compromised, which is undesirable for highly sensitive roles like Subscription Owner.

Disable the 'Require approval' setting and use 'Require MFA' only.

Why wrong: Disabling approval removes a critical security layer. For a sensitive role like 'Owner', MFA alone may not be sufficient according to many organizational security policies. The goal is to ensure the request is valid and authorized, which requires human oversight in high-security scenarios.

A trigger based on the 'createdDateTime' attribute with an 'equalTo' operator.

Why wrong: An 'equalTo' operator on the creation date would trigger the workflow immediately when the account is created. It would not provide the 30-day delay required for the onboarding survey. This operator is best for day-one tasks rather than follow-up activities.

A trigger based on the 'lastSignInDateTime' attribute.

Why wrong: The last sign-in date is unpredictable and does not correlate with the employee's hire date. Using this would result in surveys being sent at irregular times or not at all if the user hasn't signed in recently, making it unsuitable for a standardized onboarding milestone.

A manual trigger initiated by the HR Manager.

Why wrong: While manual triggers are possible, they do not meet the requirement for an 'automatic' workflow. Manual triggers require human intervention for every employee, which is prone to error and does not leverage the automation capabilities of Lifecycle Workflows to scale the onboarding process.

Auto-apply results to resource.

Why wrong: While 'Auto-apply' is a feature of Access Reviews, it is not a 'decision helper'. It is an action taken after the review is complete. Decision helpers are intended to provide information *to* the reviewer before they make a choice, rather than automating the outcome of that choice.

Multi-Factor Authentication status.

Why wrong: The MFA status of a user is not currently provided as a standard 'decision helper' recommendation within the Access Review interface. While MFA is important for security, Access Reviews focus more on whether the user's business need for the specific resource still exists based on activity and organizational patterns.

Conditional Access policy count.

Why wrong: The number of Conditional Access policies applying to a user does not help a reviewer determine if the user still needs membership in a specific group. This metric is irrelevant to the governance goal of verifying that the right people have the right access to specific resources.

Create a policy for 'All users (All members)' and add an approval step.

Why wrong: While this allows everyone to request and adds a human check, it doesn't automatically restrict requests based on the 'Sales' attribute. It would result in many invalid requests that managers would have to manually deny, which is inefficient and does not meet the specific attribute-based requirement.

Set the 'Hidden' property of the access package to 'Yes'.

Why wrong: Setting a package to 'Hidden' makes it undiscoverable for all users unless they have the direct link. This contradicts the requirement to make the package discoverable by employees. It also doesn't enforce any attribute-based restrictions once a user obtains the link and tries to request it.

Use a Conditional Access policy to block non-Sales users from the MyAccess portal.

Why wrong: Blocking the entire MyAccess portal for non-Sales users would prevent them from requesting any other packages they might be eligible for. This is a heavy-handed approach that lacks the granularity needed to manage access to a single specific package within the Entitlement Management system.

A Conditional Access policy with session frequency controls.

Why wrong: Conditional Access policies manage the conditions under which a user signs in, such as location or device state, but they do not manage the lifecycle of resource memberships. Using this feature would not allow for the automated expiration of SharePoint site access or the manager-based approval workflow required here.

A guest user account with a manual expiration date in Entra ID.

Why wrong: Creating individual guest accounts manually fails to address the requirement for automated expiration or a formal approval workflow. This method is administrative heavy and prone to human error, leading to stale accounts that retain access indefinitely, which significantly increases the security risk profile for the organization's sensitive collaborative data.

An access package in Entitlement Management with a lifecycle policy.

Why wrong: This configuration correctly utilizes the Entitlement Management feature set to automate the lifecycle of external access. By grouping resources and setting a 90-day lifecycle with external manager approval, the organization ensures that access is only granted when necessary and is automatically revoked when the project duration concludes.

A periodic access review for the Microsoft Team and SharePoint site.

Why wrong: Access reviews are useful for periodic auditing but do not provide the initial request-and-approval mechanism required for the onboarding phase described. Relying solely on reviews means users might gain access without proper initial vetting, and the 90-day requirement would be harder to enforce as a strict hard-stop expiration.

A role-assignable security group with an Eligible assignment.

Why wrong: Role-assignable groups are the prerequisite for using PIM to manage group memberships securely. Setting the assignment to Eligible ensures the user does not have the group's permissions by default, requiring a manual activation step that honors the 4-hour limit and provides a clear audit trail for administrative activities.

A standard Microsoft 365 group with an Active assignment.

Why wrong: Standard Microsoft 365 groups do not support the role-assignment property required for robust PIM integration in many scenarios. Furthermore, an Active assignment grants the user permanent access without the need for activation, which directly contradicts the requirement to limit access duration and require a formal request for elevation.

A dynamic membership security group with an Eligible assignment.

Why wrong: Dynamic membership groups calculate their members based on user attributes and do not support Eligible assignments in PIM. Because membership is automated based on rules, the concept of a user manually activating their membership is incompatible with the logic-driven nature of dynamic groups, making this an invalid technical choice.

A role-assignable security group with an Active assignment.

Why wrong: While using a role-assignable group is correct, choosing an Active assignment grants the user the group's permissions immediately and permanently. This configuration bypasses the PIM activation workflow entirely, meaning the user would not need to request access or be restricted by the specific 4-hour window you intended to enforce.

Send a 'Welcome' email to the new hire.

Why wrong: Sending a welcome email is a built-in task within Lifecycle Workflows that helps streamline the communication process. It allows IT to provide essential information, such as login instructions or company policies, to the user's personal or alternative email address before they have fully accessed their corporate mailbox.

Assign a Microsoft 365 E5 license to the user.

Why wrong: License assignment is typically handled through group-based licensing or manual assignment rather than being a direct native task within Lifecycle Workflows. While workflows can add users to groups that have licenses assigned, the act of assigning the license itself is not a standalone task in the workflow engine.

Create a new user account in an on-premises Active Directory.

Why wrong: Lifecycle Workflows operate on existing objects within Microsoft Entra ID and do not natively support the creation of accounts in on-premises environments. Account provisioning from on-premises to the cloud is usually handled by Entra Connect or cloud sync, rather than being triggered by a Joiner workflow task.

Add the user to a specific set of security groups.

Why wrong: Automating the addition of users to specific security groups or Microsoft 365 groups is a primary function of Lifecycle Workflows. This ensures that permissions are granted based on the user's attributes in the HR system, maintaining a consistent and secure access model without requiring manual intervention from the helpdesk team.

Provision the user into a third-party SaaS application.

Why wrong: While Entra ID supports app provisioning via SCIM, this is a separate service integrated at the application level. Lifecycle Workflows can add a user to a group that triggers provisioning, but the workflow itself does not contain a native task to directly create an account inside a third-party SaaS platform.

The guest user will retain access until the next review cycle begins.

Why wrong: This outcome would only occur if the default decision was set to 'Approve' or if 'autoApplyDecisionsEnabled' was set to false. Because the policy explicitly defines a 'Deny' action for non-responses, the system will not allow the user to keep their access by default if the reviewer remains silent.

The guest user's access to the resource will be automatically revoked.

Why wrong: The configuration specifies 'defaultDecision': 'Deny' and 'autoApplyDecisionsEnabled': true. This means that at the end of the review period, if no decision has been recorded by the administrator, the system will automatically treat the review as a denial and remove the user's access to the associated resource.

An alert will be sent to the Global Administrator to make a manual decision.

Why wrong: While Entra ID can send reminders to reviewers, the JSON configuration shown is designed for automation. The 'autoApplyDecisionsEnabled' flag is specifically intended to prevent manual bottlenecks by executing the default decision automatically, rather than escalating the task to a Global Administrator for manual resolution at the last minute.

The review period will be extended by 7 days automatically.

Why wrong: Microsoft Entra access reviews do not support an automated 'extension' feature based on reviewer inactivity. Once the defined end date of the review cycle is reached, the system processes the results based on the existing responses or the configured default decision, regardless of whether the reviewer has finished.

Access Package Manager

Why wrong: An Access Package Manager can create and manage access packages within a catalog, but they cannot add new resources like groups or applications to that catalog. This role is too restrictive if the project lead needs to bring in new resources to be shared with their team or partners.

Identity Governance Administrator

Why wrong: The Identity Governance Administrator is a highly privileged role that can manage all catalogs, access reviews, and PIM settings across the entire organization. Assigning this role to a project lead violates the principle of least privilege, as it grants far more power than is necessary for managing a single project.

User Administrator

Why wrong: The User Administrator role focuses on managing user accounts, password resets, and group memberships at the tenant level. It does not provide specific administrative rights within the Entitlement Management catalog structure, making it unsuitable for a user who needs to manage access packages and catalog resources for a project.

Catalog Owner

Why wrong: The Catalog Owner role is designed for delegation, allowing a user to manage the lifecycle of a specific catalog. This includes adding resources, managing access packages, and assigning other users to roles within that catalog, providing the project lead with complete control over their specific project assets only.