Manage Azure identities and governance

The correct answer is: The operation fails as the lock propagates to all resources within the group.

In Azure, management locks applied at a parent scope (such as a Resource Group) are inherited by all resources contained within that scope. Therefore, the CanNotDelete lock on 'RG-Finance' is effectively applied to the virtual machine inside it.

Crucially, management locks apply to all users, including those with the Owner role. While an Owner has the permission to create or remove locks, they cannot perform the restricted action (in this case, deletion) while the lock is still in place. The deletion attempt will be blocked by Azure Resource Manager until the lock is explicitly removed.

Why the other answers are incorrect:
- The deletion does not complete successfully because, although CanNotDelete permits read and write operations (configuration changes), it specifically prohibits deletion.
- The system does not archive resources to a recovery vault in this scenario; resource locks simply cause the API request for deletion to fail.
- The Owner role does not automatically override the lock settings; the lock enforces a restriction that supersedes RBAC permissions until the lock itself is removed.

The correct solution is to apply the role assignment at the 'RG-Finance' resource group scope.

In Azure Role-Based Access Control (RBAC), permissions are inherited from parent scopes to child scopes. The hierarchy is Management Group > Subscription > Resource Group > Resource.

By assigning the role at the Resource Group scope:
1. Inheritance: The user automatically gains permissions for all resources currently inside the group and any future resources created within it.
2. Isolation: The user qualifies for the specific role only within the boundaries of 'RG-Finance'. They receive no permissions for other resource groups or the subscription level, satisfying the requirement to restrict access outside of this specific group.

Why the other options are incorrect:
- Assigning the role at the subscription scope would grant the user control over virtual machines in all resource groups within the subscription, violating the 'no permissions outside of this resource group' requirement.
- Assigning the role at the management group scope would grant access across multiple subscriptions, which is far too broad.
- Assigning the role directly to each virtual machine is administratively difficult and does not automatically grant permissions for 'future' virtual machines created in the group.

The correct solution is to configure a SAML/WS-Fed identity provider. Microsoft Entra External Identities allows you to set up direct federation with partner organizations that use identity providers supporting the SAML 2.0 or WS-Federation protocols. Since Litware uses an on-premises solution supporting SAML 2.0 and does not have an existing Microsoft Entra tenant or Google federation, configuring a SAML/WS-Fed IdP establishes the trust relationship required for Litware users to authenticate using their own credentials.

Establishing a federation in Custom domain names is incorrect because that feature is used for federating your own domains with your own on-premises Active Directory, not for B2B guest scenarios.

Defining a connected organization in Entitlement Management helps manage access lifecycle and access packages but does not establish the underlying authentication trust with a non-Entra ID identity provider.

Creating a B2B Direct Connect inbound policy is used specifically for Microsoft Teams shared channels with other Microsoft Entra organizations, not for general B2B guest access with third-party SAML providers.