Explanation:
The web app needs to authenticate individual users (not a service principal) and obtain OAuth 2 bearer tokens to call the back-end web API. This requires Microsoft Entra ID as the token issuer and the web API to perform authorization decisions. The flow is: user authenticates to Entra ID → web app receives token → web app passes token to web API → web API validates token and checks permissions.

Correct Options:

The access tokens will be generated by: Microsoft Entra ID
Microsoft Entra ID is the identity provider and OAuth 2.0 authorization server. It issues access tokens after authenticating individual users. Neither the web app nor the web API can generate valid OAuth 2 bearer tokens. The web app requests tokens from Entra ID, and the web API consumes them.

Authorization decisions will be performed by: A web API
The back-end web API receives the access token and validates claims (scopes, roles, app permissions) to determine whether the request is authorized. Microsoft Entra ID issues the token but does not enforce authorization at runtime. The web API implements its own authorization logic based on token contents.

Reference:
Microsoft Learn: OAuth 2.0 authorization code flow; Microsoft Entra ID access tokens; Protect a web API using Microsoft Entra ID.

Explanation:
To provide users from fabrikam.com access to contoso.com resources using access packages in Microsoft Entra Identity Governance, you must first define fabrikam.com as a connected organization. A connected organization represents an external tenant that you collaborate with. Only after adding a connected organization can you specify external users as allowed requestors or assignees in access packages.

Correct Option:

A. From the Entitlement management settings in Identity Governance, create a new connected organization.
Connected organizations are the prerequisite for entitlement management to recognize and allow external tenants like fabrikam.com. Once fabrikam.com is added as a connected organization, Access package assignment managers can assign access packages specifically to users from that external tenant. Without this, external users cannot be targeted in access packages.

Incorrect Options:

B. Cross-tenant access settings
Cross-tenant access settings control B2B collaboration authentication and trust policies (inbound/outbound access), but they do not create the entitlement management relationship required for access packages. This is a separate external identities feature, not the first step for access package assignment to external users.

C. Cross-tenant synchronization settings
Cross-tenant synchronization is used to automatically synchronize users from an external tenant as B2B users and keep their attributes updated. This is optional and not required for ad-hoc access package assignments. It does not define the partner organization for entitlement management purposes.

D. SAML/WS-Fed IdP identity provider
SAML/WS-Fed IdP settings are used to add external identity providers for social or enterprise identity federation (e.g., Google, Facebook, or custom SAML 2.0 providers). This is not relevant for a partner that already has its own Microsoft Entra tenant. Fabrikam.com is already a Microsoft Entra tenant, not a third-party IdP.

Reference:
Microsoft Learn: Configure a connected organization in Entitlement Management; Assign access packages to external users.

Explanation:
The goal is to minimize network latency between Azure virtual machines (application tier) and an Azure BareMetal Infrastructure instance (data tier). Proximity placement groups (PPGs) are designed to co-locate resources in the same Azure datacenter or region, reducing physical distance and network latency between different compute types including VMs and BareMetal instances.

Correct Option:

D. A proximity placement group
Proximity placement groups explicitly co-locate multiple Azure resources such as VMs, scale sets, and BareMetal Infrastructure instances within the same physical datacenter. This minimizes network latency between application tier VMs and BareMetal data tier. PPGs are the recommended solution for low-latency workloads spanning different compute families in Azure.

Incorrect Options:

A. An availability zone
Availability zones isolate resources across physically separate datacenters to provide high availability, but they introduce higher network latency due to inter-zone communication. This would increase latency rather than minimize it. Zones are for fault isolation, not proximity optimization.

B. ExpressRoute FastPath
ExpressRoute FastPath improves data path performance between on-premises networks and Azure VMs by bypassing the ExpressRoute gateway. This does not apply to communication between Azure VMs and Azure BareMetal Infrastructure within the same Azure region. FastPath is for hybrid connectivity, not intra-Azure workloads.

C. An availability set
Availability sets distribute VMs across fault and update domains to improve availability, but they do not guarantee physical proximity or reduced latency. VMs in an availability set can still be placed on different racks or clusters. Availability sets do not co-locate with BareMetal instances.

Reference:
Microsoft Learn: Proximity placement groups for Azure VMs; Co-locate BareMetal Infrastructure with proximity placement groups.

Explanation:
The Azure SQL Migration extension for Azure Data Studio requires a target schema to be defined before migration. The extension assesses the source database and can generate a schema script, but you must first define or prepare the target schema structure (tables, indexes, views) in the Azure SQL database. This is a prerequisite step before running the actual migration.

Correct Option:

B. Define the schema for the Azure SQL database.
Before migrating data, the target Azure SQL database must have the schema (tables, constraints, indexes) defined. The migration tool maps source data to target schema elements. Without a predefined schema, the migration cannot place data into proper structures. You can script the schema from the source and apply it to the target as the first action.

Incorrect Options:

A. Configure a Site-to-Site (S2S) VPN connection.
S2S VPN is not required for Azure SQL Database migration because Azure SQL Database is a PaaS service accessible over the internet with proper firewall rules and authentication. The migration extension uses standard TDS connectivity, not a VPN. This would be unnecessary and not the first step.

C. Create a user-assigned managed identity.
A managed identity may be used for authentication between Azure services, but it is not required for the initial migration step. The Azure Data Studio extension typically uses SQL authentication or Azure AD authentication directly. This is an optional configuration, not the first prerequisite.

D. Upgrade DB1.
Azure SQL Database supports migration from SQL Server 2016 directly. No upgrade is required because Azure SQL Database is compatible with SQL Server 2016 feature set. The migration extension handles compatibility checks and can identify any issues without upgrading the source database first.

Reference:
Microsoft Learn: Migrate SQL Server to Azure SQL Database using Azure Data Studio; Prerequisites for Azure SQL Migration extension.

Explanation:
The goal is to prevent a compromised administrator account in contoso.com from modifying backup policies and deleting backups. Adding PIM approval requirements still allows the compromised account to request and potentially receive approval for activation. Since the approver is also in contoso.com, a compromised account could target a compromised or unwitting approver, or the approver's account could also be compromised.

Correct Option:

B. No
PIM with approval from an administrator within the same tenant does not prevent a compromised account from ultimately gaining privileged roles. The approver exists in the same compromised environment. Additionally, PIM controls who can activate roles but does not add an external safeguard. To truly protect backups, you need an out-of-band control such as multi-tenant or subscription-level immutable vault locks.

Incorrect Option:
A. Yes is incorrect because requiring approval within the same tenant does not add a meaningful barrier against a compromised administrator. The attacker could compromise the approver's account as well or exploit social engineering. The solution fails to introduce an independent second party (like Fabrikam) or an immutable control outside contoso.com's administrative reach.

Reference:
Microsoft Learn: Privileged Identity Management approval workflow overview; Protect backup data with Azure Backup immutable vault.

Explanation:
The application uses three-part naming (server.database.table) to reference tables across multiple databases. This requires a SQL environment that supports cross-database queries and multiple databases under a single logical server. Azure SQL Database (single database or elastic pool) does not fully support cross-database queries with three-part names across different databases without Elastic Query features.

Correct Options:

A. Azure SQL Managed Instance
Supports three-part naming for cross-database queries natively because it provides near 100% SQL Server engine compatibility. You can have multiple databases within a single managed instance and reference them using database names directly. This makes migration of existing applications straightforward without code changes.

D. SQL Server on an Azure virtual machine
Provides full SQL Server instance-level control and supports cross-database queries with three-part naming exactly like on-premises SQL Server. You can host multiple databases on the same VM instance and reference server, database, and table names without modification. This is a complete lift-and-shift solution.

Incorrect Options:

B. Azure SQL Database
Single Azure SQL Database does not support cross-database queries using three-part naming across different databases. While Elastic Query can provide limited cross-database querying, it requires rewriting T-SQL code and does not offer native three-part name support. This would break the existing application logic.

C. SQL Server Stretch Database
This feature is deprecated and was used to extend on-premises SQL Server databases to Azure by archiving cold data transparently. It does not support migrating full application data with cross-database queries. It is not a complete migration solution for the described application requirements.

Reference:
Microsoft Learn: Features comparison between Azure SQL Database and Azure SQL Managed Instance; Cross-database queries in Azure SQL Managed Instance; SQL Server on Azure Virtual Machines overview.

Explanation:
The question focuses on enforcing data modification requirements for an application (App1) after migrating to Azure. Data modification controls at the storage object level (blobs) require fine-grained access management. Shared access signatures (SAS) or stored access policies are used to control permissions like add, create, update, and delete on blob containers or blobs.

Correct Option:

B. Create an access policy for the blob service.
Stored access policies allow you to define precise permissions (read, write, delete, add, create) at the blob container level. They can be used to delegate specific modification permissions with time-bound limits or revocation capabilities. This directly enforces data modification controls without granting overly broad account-level access.

Incorrect Options:

A. Create Azure RBAC assignments.
RBAC (e.g., Storage Blob Data Contributor) manages identity-based access at the subscription, resource group, or storage account level. While it controls modification, it is broader and less granular than a stored access policy for specific blob containers or time-bound signatures. Not the best answer for enforcing specific modification requirements tied to the blob service.

C. Modify the access level of the blob service.
Access level (private, blob, container) controls anonymous public read access, not authenticated modification permissions. Changing this does not enforce who can modify data or under what conditions. It addresses confidentiality, not controlled modification.

D. Implement Azure resource locks.
Resource locks prevent accidental deletion or modification of Azure resources (e.g., the storage account itself), not the data inside blobs. A lock at resource level does not control blob create/update/delete operations. This is for infrastructure protection, not data modification compliance.

Reference:
Microsoft Learn: Create a stored access policy for Azure Blob Storage; Grant limited access using shared access signatures.