You save $69.98
An Azure administrator must resolve a specific request: A company buys a premium Entra subscription for temporary workers who have internal Microsoft Entra member accounts (not B2B guests), with group membership changing every month. The expected outcome is: assign paid features only to approved group members and remove entitlement after departure. Which option is appropriate?
Group-based licensing ties entitlement to membership and reduces manual license assignment drift. The decisive requirement is: assign paid features only to approved group members and remove entitlement after departure. This choice should be implemented at the appropriate Azure service boundary while retaining the specifically permitted business workflow.
Tenant-wide licensing wastes purchased capacity and ignores eligibility. The stated requirement is: assign paid features only to approved group members and remove entitlement after departure. Unlike the selected solution, this choice would leave the relevant authorization, availability or configuration boundary unresolved.
Group membership determines eligibility but does not itself grant the premium feature. The administrator must assign the intended license SKU to the group and verify available license capacity; a group without an associated license assignment leaves approved contractors unlicensed.
Azure RBAC Reader grants viewing rights for Azure resources; it is not the Microsoft Entra licensing mechanism. That role could be appropriate for resource inventory, but it neither allocates premium identity product licenses nor removes them based on contractor group membership.
Operations sees an unexpected outcome: An internal tenant-member contractor has joined the authorized group but the premium feature shows as unavailable. The original demand was: assign paid features only to approved group members and remove entitlement after departure. Which cause is most consistent with the evidence?
The trace reports: An internal tenant-member contractor has joined the authorized group but the premium feature shows as unavailable. The causal misconfiguration is: Group license assignment failed or the account has an unresolved licensing error or missing capacity. The targeted action is to inspect the group license assignment and resolve the specific user licensing error or SKU capacity issue.
The guest identity exists but lacks the required application assignment or resource permissions; that mechanism would be more consistent with an observation such as the invited engineer can sign in but sees an authorization-denied page for the required app, rather than this case's an internal tenant-member contractor has joined the authorized group but the premium feature shows as unavailable.
The access group uses static membership or an incorrect dynamic rule instead of the intended department condition; that mechanism would be more consistent with an observation such as a transferred researcher retains membership after their department attribute changes, rather than this case's an internal tenant-member contractor has joined the authorized group but the premium feature shows as unavailable.
The provisioning process has no validated record-to-identity mapping or reconciliation step; that mechanism would be more consistent with an observation such as several new hires are missing or have incorrect user principal names after an ad hoc provisioning effort, rather than this case's an internal tenant-member contractor has joined the authorized group but the premium feature shows as unavailable.
A service owner needs a practical fix after this failure: An internal tenant-member contractor has joined the authorized group but the premium feature shows as unavailable. What is the best remediation?
Inspect the group license assignment and resolve the specific user licensing error or SKU capacity issue. This addresses the documented failure condition: group license assignment failed or the account has an unresolved licensing error or missing capacity. Retest the affected operation and retain the original least-privilege boundaries.
Tenant-wide licensing wastes purchased capacity and ignores eligibility. In the reported incident (an internal tenant-member contractor has joined the authorized group but the premium feature shows as unavailable), that change would not correct the cause: group license assignment failed or the account has an unresolved licensing error or missing capacity.
A naming convention cannot grant a product license. In the reported incident (an internal tenant-member contractor has joined the authorized group but the premium feature shows as unavailable), that change would not correct the cause: group license assignment failed or the account has an unresolved licensing error or missing capacity.
Azure RBAC Owner is not the same as an Entra product license. In the reported incident (an internal tenant-member contractor has joined the authorized group but the premium feature shows as unavailable), that change would not correct the cause: group license assignment failed or the account has an unresolved licensing error or missing capacity.
A deployment claims to meet: assign paid features only to approved group members and remove entitlement after departure. The environment is: A company buys a premium Entra subscription for temporary workers who have internal Microsoft Entra member accounts (not B2B guests), with group membership changing every month. Which TWO test results would substantiate that claim? Select TWO answers.
Check license-assignment state for a newly added eligible contractor. This supplies observed evidence for assign paid features only to approved group members and remove entitlement after departure. It is not interchangeable with the second required check, remove a test contractor from the group and confirm assignment is recalculated, because that checks a separate success or failure boundary.
Remove a test contractor from the group and confirm assignment is recalculated. This supplies observed evidence for assign paid features only to approved group members and remove entitlement after departure. It is not interchangeable with the second required check, check license-assignment state for a newly added eligible contractor, because that checks a separate success or failure boundary.
A configured resource is not proof of live behavior. The relevant result must be observed by checking license-assignment state for a newly added eligible contractor on the affected Azure deployment.
A privileged administrator in a different subscription may succeed at 'Check license-assignment state for a newly added eligible contractor' even though the intended caller fails. This does not prove the required behavior for the check license-assignment state for a newly added eligible contractor.
A release checklist recording 'Remove a test contractor from the group and confirm assignment is recalculated' is not evidence that the required operation actually succeeded or failed. To establish the correct result, the team must remove a test contractor from the group and confirm assignment is recalculated on the actual workload to prove its independent boundary.
An infrastructure design was selected to meet: assign paid features only to approved internal tenant-member contractors and remove entitlement after departure. What caveat remains relevant during operation?
Group membership does not guarantee license activation when dependencies or available capacity are missing. That remains a practical service boundary even after the recommended change (apply group-based licensing to a dedicated security group with the required license SKU and available capacity) is implemented; retest it when identities, policies, service capacity or network paths change.
The successful check 'Check license-assignment state for a newly added eligible contractor' proves only the tested behavior and cannot eliminate every dependent failure. The specific remaining limitation is: Group membership does not guarantee license activation when dependencies or available capacity are missing.
The two checks cover separate behavior: 'Check license-assignment state for a newly added eligible contractor' and 'Remove a test contractor from the group and confirm assignment is recalculated'. Neither check removes the remaining operational limitation: Group membership does not guarantee license activation when dependencies or available capacity are missing.
The incident (an internal tenant-member contractor has joined the authorized group but the premium feature shows as unavailable) could recur if a related Azure dependency changes. The design still faces the limitation: Group membership does not guarantee license activation when dependencies or available capacity are missing.
A production subscription has this use case: A firm brings external auditors into a project for two weeks and expects their access to end after review. The owner specifies: restrict external identity access for a defined engagement and clean it up when the engagement ends. What is the best administrative approach?
Named guests and explicit expiry review make the temporary arrangement attributable and revocable. This achieves restrict external identity access for a defined engagement and clean it up when the engagement ends through provision named B2B guests with narrowly scoped access and a scheduled review/removal process instead of relying on merely similar resource settings.
A shared guest identity obscures who accessed the evidence; that would not meet restrict external identity access for a defined engagement and clean it up when the engagement ends, for which the relevant Azure action is provision named B2B guests with narrowly scoped access and a scheduled review/removal process.
Permanent privileged roles exceed the temporary evidence review; that would not meet restrict external identity access for a defined engagement and clean it up when the engagement ends, for which the relevant Azure action is provision named B2B guests with narrowly scoped access and a scheduled review/removal process.
Public sharing bypasses the stated access restrictions; that would not meet restrict external identity access for a defined engagement and clean it up when the engagement ends, for which the relevant Azure action is provision named B2B guests with narrowly scoped access and a scheduled review/removal process.
An Azure administrator is investigating this symptom: An external reviewer continues accessing sensitive documents months after the audit ends. Which root cause best matches the underlying requirement: restrict external identity access for a defined engagement and clean it up when the engagement ends?
The trace reports: An external reviewer continues accessing sensitive documents months after the audit ends. The causal misconfiguration is: The guest account and underlying group or application assignment were not removed at engagement closure. The targeted action is to remove the expired guest's resource assignment and disable or delete access according to retention policy.
The guest identity exists but lacks the required application assignment or resource permissions; that mechanism would be more consistent with an observation such as the invited engineer can sign in but sees an authorization-denied page for the required app, rather than this case's an external reviewer continues accessing sensitive documents months after the audit ends.
The provisioning process has no validated record-to-identity mapping or reconciliation step; that mechanism would be more consistent with an observation such as several new hires are missing or have incorrect user principal names after an ad hoc provisioning effort, rather than this case's an external reviewer continues accessing sensitive documents months after the audit ends.
The access group uses static membership or an incorrect dynamic rule instead of the intended department condition; that mechanism would be more consistent with an observation such as a transferred researcher retains membership after their department attribute changes, rather than this case's an external reviewer continues accessing sensitive documents months after the audit ends.
An Azure rollout fails because: An external reviewer continues accessing sensitive documents months after the audit ends. Which change most directly restores the intended control?
Remove the expired guest's resource assignment and disable or delete access according to retention policy. This addresses the documented failure condition: the guest account and underlying group or application assignment were not removed at engagement closure. Retest the affected operation and retain the original least-privilege boundaries.
Permanent privileged roles exceed the temporary evidence review. In the reported incident (an external reviewer continues accessing sensitive documents months after the audit ends), that change would not correct the cause: the guest account and underlying group or application assignment were not removed at engagement closure.
A shared guest identity obscures who accessed the evidence. In the reported incident (an external reviewer continues accessing sensitive documents months after the audit ends), that change would not correct the cause: the guest account and underlying group or application assignment were not removed at engagement closure.
Public sharing bypasses the stated access restrictions. In the reported incident (an external reviewer continues accessing sensitive documents months after the audit ends), that change would not correct the cause: the guest account and underlying group or application assignment were not removed at engagement closure.
For the configuration goal, restrict external identity access for a defined engagement and clean it up when the engagement ends. The Azure context is: A firm brings external auditors into a project for two weeks and expects their access to end after review. Which TWO observations provide useful assurance? Select TWO answers.
Verify the former guest cannot open the evidence application after expiry. This supplies observed evidence for restrict external identity access for a defined engagement and clean it up when the engagement ends. It is not interchangeable with the second required check, confirm current invited auditors can still read only their approved folders, because that checks a separate success or failure boundary.
Confirm current invited auditors can still read only their approved folders. This supplies observed evidence for restrict external identity access for a defined engagement and clean it up when the engagement ends. It is not interchangeable with the second required check, verify the former guest cannot open the evidence application after expiry, because that checks a separate success or failure boundary.
A privileged administrator in a different subscription may succeed at 'Verify the former guest cannot open the evidence application after expiry' even though the intended caller fails. This does not prove the required behavior for verify the former guest cannot open the evidence application after expiry.
A release checklist recording 'Confirm current invited auditors can still read only their approved folders' is not evidence that the required operation actually succeeded or failed. To establish the correct result, the team must confirm current invited auditors can still read only their approved folders on the actual workload to prove its independent boundary.
A configured resource is not proof of live behavior. The relevant result must be observed by verifying the former guest cannot open the evidence application after expiry on the affected Azure deployment.
A stakeholder asks whether the proposed configuration guarantees: restrict external identity access for a defined engagement and clean it up when the engagement ends. What qualification is technically accurate?
B2B guest lifecycle controls do not automatically revoke all third-party application sessions unless those sessions are handled. That remains a practical service boundary even after the recommended change (provision named B2B guests with narrowly scoped access and a scheduled review/removal process) is implemented; retest it when identities, policies, service capacity or network paths change.
The two checks cover separate behavior: 'Verify the former guest cannot open the evidence application after expiry' and 'Confirm current invited auditors can still read only their approved folders'. Neither check removes the remaining operational limitation: B2B guest lifecycle controls do not automatically revoke all third-party application sessions unless those sessions are handled.
The incident (an external reviewer continues accessing sensitive documents months after the audit ends) could recur if a related Azure dependency changes. The design still faces the limitation: B2B guest lifecycle controls do not automatically revoke all third-party application sessions unless those sessions are handled.
The successful check 'Verify the former guest cannot open the evidence application after expiry' proves only the tested behavior and cannot eliminate every dependent failure. The specific remaining limitation is: B2B guest lifecycle controls do not automatically revoke all third-party application sessions unless those sessions are handled.
or Guarantee your success by buying the full version which covers the full latest pool of questions. (606 Questions, Last Updated on Oct 25, 2026)
Please check your mailbox for a message from support@examlabs.com and follow the directions.
