All practice questions

1198 questions

All types1,198 Multiple choice617 Multiple select502 Matching65 Ordering14

You are designing a secure network architecture for an application in Azure. The application consists of Azure Virtual Machines deployed in a subnet named Subnet1 within a virtual network named VNet1. The virtual machines must access an Azure Storage account named storage1 to retrieve configuration files. You need to recommend a solution that ensures all traffic from Subnet1 to storage1 flows over the Microsoft backbone network and that public access to storage1 from the internet is completely blocked. Which two actions should you include in the recommendation?

Select all that apply

Create a Private Endpoint for storage1 in Subnet1.

Configure the firewall of storage1 to disable public network access.

Configure a Network Security Group (NSG) rule in Subnet1 that allows outbound traffic to the individual public IP addresses of storage1.

Configure a custom Route Table on Subnet1 with a User Defined Route (UDR) that routes all traffic destined for storage1 to the default internet gateway.

Show answer & explanation

Answer: Create a Private Endpoint for storage1 in Subnet1.; Configure the firewall of storage1 to disable public network access.

Answer

Create a Private Endpoint for storage1 in Subnet1 and configure the firewall of storage1 to disable public network access.

To secure access to the storage account, you must establish private connectivity and disable public access. Creating a Private Endpoint in the virtual network subnet assigns a private IP address to the storage account, routing traffic over the Microsoft backbone. Disabling public network access on the storage account firewall blocks all access from the public internet.

Step-by-Step Solution

Identify the requirement for private connectivity over the Microsoft backbone.

Determine that a Private Endpoint is needed to assign a private IP from the virtual network to the storage account.

Private Endpoints ensure traffic remains on the Microsoft backbone and is not routed over the public internet.

Identify the requirement to block all public internet access to the storage account.

Determine that the storage account firewall must be configured to disable public network access.

By default, storage accounts accept connections from any network. Disabling public access enforces private-only access.

Key Concept

Azure Private Link and Storage Account Firewalls

Alternative Method

Instead of Private Endpoints, you could use Service Endpoints combined with Storage Firewall virtual network restrictions, but Private Endpoints are preferred when you must completely block all public access paths.

Estimated Time:45s

Question 622Question →

An organization needs to host a containerized background processing application in Azure. The application retrieves items from an Azure Queue Storage queue and processes them. The processing time for a single queue item is consistently $15$ minutes. The architecture team requires that the solution automatically scales based on the number of queue messages, minimizes management effort, and avoids paying for compute resources when the queue is empty. Which Azure compute solution should you recommend?

Azure Container Apps

Azure Functions deployed with a Consumption-based hosting model

Azure Kubernetes Service (AKS)

Azure Spot Virtual Machine Scale Sets

Show answer & explanation

Answer: Azure Container Apps

Answer

Azure Container Apps

Azure Container Apps is the correct recommendation. It is a serverless container hosting service that automatically scales to zero when no messages are in the queue (leveraging KEDA event-driven scaling), manages the underlying infrastructure to minimize administrative overhead, and does not enforce a strict 10-minute timeout limit, allowing the 15-minute executions to complete successfully.

Step-by-Step Solution

Analyze the execution duration constraint.

The background job takes

15

minutes to process a single item.

This rules out serverless hosting plans that enforce a strict timeout limit below

15

minutes.

Evaluate scale-to-zero and management overhead requirements.

The solution must scale to zero when idle to minimize costs, and minimize administrative overhead.

This rules out full orchestrators like Azure Kubernetes Service (AKS) due to high management overhead, and virtual machines which do not scale to zero automatically based on queue depth.

Compare the remaining options to select the optimal service.

Azure Container Apps supports containerized execution, scales to zero using KEDA based on queue length, has minimal management overhead, and supports execution times longer than

10

minutes.

It fulfills all requirements: serverless scaling, no execution limits, container support, and low management overhead.

Key Concept

Selecting serverless container compute based on execution timeouts and management overhead

Estimated Time:1m 0s

Question 623Question →

An organization is designing a disaster recovery (DR) solution for a smart energy analytics platform hosted on Azure virtual machines in the UK South region. The target DR region is UK West. The platform consists of three tiers:

* Web Tier: Two virtual machines. Each virtual machine has one Standard SSD operating system (OS) disk with a write churn of $0.5\text{ MB/s}$ .
* Application Tier: Two virtual machines. Each virtual machine has one Standard SSD OS disk with a write churn of $1.5\text{ MB/s}$ .
* Database Tier: Two virtual machines running SQL Server Enterprise. Each virtual machine has one Standard SSD OS disk ( $2\text{ MB/s}$ churn), two Premium SSD (P30) data disks ( $24\text{ MB/s}$ churn per disk), and one Premium SSD (P20) log disk ( $28\text{ MB/s}$ churn).

The solution must meet the following business requirements:

* The web and application tiers must have a Recovery Point Objective (RPO) of $2\text{ hours}$ and a Recovery Time Objective (RTO) of $4\text{ hours}$ .
* The database tier must have an RPO of $10\text{ seconds}$ and an RTO of $15\text{ minutes}$ .

Which two recommendations should you include in the disaster recovery design? (Select two.)

Select all that apply

Replicate the web and application tier virtual machines to the target region by using Azure Site Recovery.

Configure SQL Server Always On Availability Groups to replicate the database tier to the target region.

Replicate the database tier virtual machines to the target region by using Azure Site Recovery with a high-churn replication policy.

Configure Azure Backup with Cross-Region Restore (CRR) to replicate the database tier virtual machines.

Show answer & explanation

Answer: Replicate the web and application tier virtual machines to the target region by using Azure Site Recovery.; Configure SQL Server Always On Availability Groups to replicate the database tier to the target region.

Answer

Replicate the web and application tier virtual machines to the target region by using Azure Site Recovery, and configure SQL Server Always On Availability Groups to replicate the database tier to the target region.

The correct disaster recovery design uses Azure Site Recovery for the web and application tier virtual machines because their write churn is low and the

2\text{ hours}

RPO and

4\text{ hours}

RTO are fully supported. For the database tier, native SQL Server Always On Availability Groups with asynchronous replication must be configured. This meets the

10\text{ seconds}

RPO and bypasses Azure Site Recovery limits, as the database disks exceed standard ASR churn thresholds of

20\text{ MB/s}

per disk and

54\text{ MB/s}

per VM.

Step-by-Step Solution

Analyze the RPO and RTO requirements for both the web/application tiers and the database tier.

The web/application tiers require an RPO of

2\text{ hours}

and RTO of

4\text{ hours}

. The database tier requires an RPO of

10\text{ seconds}

and RTO of

15\text{ minutes}

Identifying the recovery objectives determines which replication technologies can meet the constraints.

Evaluate the capability of Azure Site Recovery (ASR) to meet the RPO of the database tier.

ASR replication frequency for Azure VMs generates recovery points every few minutes, failing to support a

10\text{ seconds}

RPO.

This rules out ASR for the database tier and mandates a native replication mechanism.

Verify write churn rates of the database tier disks against ASR limits.

The database disks (

24\text{ MB/s}

and

28\text{ MB/s}

) exceed standard ASR disk-level thresholds (

20\text{ MB/s}

for P20/P30), and the total VM write churn (

78\text{ MB/s}

) exceeds the standard

54\text{ MB/s}

limit.

Verifying limits confirms that ASR is technically unsuitable for this database workload without special policy modifications, and even then fails the RPO constraint.

Evaluate the replication options for the web and application tiers.

The web and application VMs have very low write churn and their RPO/RTO requirements are fully satisfied by ASR.

Using ASR for stateless application layers minimizes administrative and replication configuration overhead.

Key Concept

Disaster recovery design involving write churn limits and RPO/RTO constraints in Azure Site Recovery.

Question 624Question →

You are designing the routing for a subnet in an Azure virtual network named `vnet-prod-spoke` ( $10.20.0.0/16$ ). You need to route all outbound internet traffic from the subnet to a firewall virtual appliance located in a peered virtual network. Traffic within `vnet-prod-spoke` ( $10.20.0.0/16$ ) must continue to route directly between subnets without passing through the firewall. Which route should you add to the User-Defined Route (UDR) table associated with the subnet?

A route for

10.20.0.0/16

with the next hop type set to None, and a route for

0.0.0.0/0

pointing to the firewall's private IP address.

A Network Security Group (NSG) outbound security rule that redirects traffic destined for the Internet service tag to the firewall's private IP address.

A route for

0.0.0.0/0

with the next hop type set to Virtual appliance and the next hop IP address set to the firewall's private IP address.

A route for

10.20.0.0/16

and a route for

0.0.0.0/0

, both with the next hop type set to Virtual appliance and the next hop IP address set to the firewall's private IP address.

Show answer & explanation

Answer: A route for $0.0.0.0/0$ with the next hop type set to Virtual appliance and the next hop IP address set to the firewall's private IP address.

Answer

A route for

0.0.0.0/0

with the next hop type set to Virtual appliance and the next hop IP address set to the firewall's private IP address.

The correct option is to define a route for

0.0.0.0/0

with the next hop set to the virtual appliance's private IP. Azure routes traffic by evaluating all available routes and selecting the one with the longest prefix match. The system-defined route for the local VNet prefix (

10.20.0.0/16

) is more specific than the user-defined route for

0.0.0.0/0

. Therefore, any traffic destined within `vnet-prod-spoke` will match the system route and route directly, while all other traffic destined for the internet will fall back to the

0.0.0.0/0

UDR and be forwarded to the firewall.

Step-by-Step Solution

Identify the target IP range for internet-bound traffic.

The target prefix is

0.0.0.0/0

This prefix represents all traffic destined outside the virtual network.

Configure the next hop type and IP address for the internet route in the route table.

Set next hop type to Virtual appliance and provide the firewall's private IP address.

This routes all traffic matching the

0.0.0.0/0

route through the firewall appliance.

Analyze how Azure's longest prefix match (LPM) handles local virtual network traffic (

10.20.0.0/16

Since

10.20.0.0/16

is a longer prefix than

0.0.0.0/0

, the default system route for the local virtual network takes precedence.

By omitting an explicit UDR for

10.20.0.0/16

, internal traffic automatically bypasses the firewall and routes directly.

Key Concept

Azure routing precedence and longest prefix match (LPM)

Question 625Question →

A company is designing a network security solution for its virtual machines (VMs) deployed in an Azure virtual network subnet. The VMs must be allowed outbound access to Azure Storage accounts only within the East US region to download updates. Outbound access to the public internet and storage accounts in other regions must be blocked. The solution must minimize administrative effort.

Which configuration should you recommend for the Network Security Group (NSG) associated with the VM subnet?

Create an outbound rule with a priority of 100 that allows traffic to the Storage.EastUS service tag, and a rule with a priority of 200 that denies traffic to the Storage service tag.

Create an outbound rule with a priority of 100 that allows traffic to the individual IP address ranges of the Azure Storage endpoints in the East US region, and a rule with a priority of 200 that denies traffic to the Storage service tag.

Create a User Defined Route (UDR) with a prefix of 0.0.0.0/0 to route all traffic to a virtual appliance, while manually creating overlapping UDRs for each individual storage IP range in East US to bypass the appliance.

Create an outbound rule with a priority of 100 that allows traffic to the Storage service tag, and configure an Application Security Group (ASG) containing the East US storage IP addresses to restrict access.

Show answer & explanation

Answer: Create an outbound rule with a priority of 100 that allows traffic to the Storage.EastUS service tag, and a rule with a priority of 200 that denies traffic to the Storage service tag.

Answer

Configure an NSG outbound rule with a priority of 100 that allows traffic to the Storage.EastUS service tag, and another rule with a priority of 200 that denies traffic to the Storage service tag.

Using regional service tags such as Storage.EastUS in combination with the broader Storage service tag is the recommended approach to restrict outbound traffic to a specific Azure service region. Since rules are processed in priority order, allowing Storage.EastUS with a higher priority (100) and denying Storage with a lower priority (200) ensures only East US storage traffic is permitted. This design requires minimal administrative effort because Azure automatically updates the IP addresses associated with the service tags.

Step-by-Step Solution

Identify the target service and regional requirements.

The target is Azure Storage in the East US region, and all other Storage regions and public internet must be blocked.

This establishes the scope of the required network security rules.

Select the appropriate Azure Network Security Group features that minimize administrative effort.

Use Azure Service Tags (specifically the regional tag Storage.EastUS and the global tag Storage) to avoid managing dynamic IP addresses.

Service tags automatically manage IP changes, fulfilling the low-administrative-overhead constraint.

Order the NSG rules by priority to allow the subset of traffic while blocking the rest.

Create a rule allowing Storage.EastUS with a higher priority (lower number, e.g., 100) and a rule denying the general Storage tag with a lower priority (higher number, e.g., 200).

NSGs process rules sequentially; the first matching rule is applied, ensuring East US is permitted and all other regions are blocked.

Key Concept

Azure NSG Service Tags and Rule Priority

Question 626Question →

ThermaLogistics operates a fleet of refrigerated shipping containers and uses Azure Blob Storage to ingest real-time temperature and telemetry data. You are designing a high availability (HA) and disaster recovery (DR) solution for this data. The solution must satisfy the following requirements:
- Maximize read availability for telemetry reporting, allowing read access to data even if the primary region experiences an outage.
- Achieve a recovery point objective (RPO) of less than 15 minutes for regional disasters.
- Minimize costs while ensuring regional redundancy.
- Ensure that the telemetry ingestion application only writes to the primary endpoint, as the secondary region does not support writes prior to a failover.

Which two actions should you perform? (Select two.)

Select all that apply

Configure the storage account to use Read-Access Geo-Redundant Storage (RA-GRS).

Configure the telemetry reporting application to query the secondary storage endpoint during a primary region outage.

Configure the telemetry ingestion application to write to both the primary and secondary storage endpoints simultaneously.

Configure the storage account to use Read-Access Geo-Zone-Redundant Storage (RA-GZRS) to minimize storage costs.

Configure the storage account to use Locally Redundant Storage (LRS) to minimize storage costs.

Show answer & explanation

Answer: Configure the storage account to use Read-Access Geo-Redundant Storage (RA-GRS).; Configure the telemetry reporting application to query the secondary storage endpoint during a primary region outage.

Answer

Configure the storage account to use Read-Access Geo-Redundant Storage (RA-GRS), and configure the telemetry reporting application to query the secondary storage endpoint during a primary region outage.

To meet the requirements, the storage account must be configured with Read-Access Geo-Redundant Storage (RA-GRS). RA-GRS replicates the data asynchronously to a secondary paired region with an RPO of under 15 minutes. It provides a read-only endpoint (suffix -secondary) that the telemetry reporting application can query to read data during a primary region outage, ensuring read HA. Since GRS is less expensive than GZRS, it satisfies the cost-minimization constraint while meeting the DR and read availability targets.

Step-by-Step Solution

Select a storage replication strategy that provides read access to the secondary region during primary region outages while minimizing costs.

Read-Access Geo-Redundant Storage (RA-GRS) is chosen because it replicates data to a secondary region, allows read access via the secondary endpoint, and is less expensive than RA-GZRS.

Meets the requirements for read availability, cost minimization, and regional disaster recovery.

Direct the reporting application to access the secondary endpoint during an outage.

The reporting application is configured to read from the storage account's secondary endpoint.

Ensures that the dashboard remains operational for reads even when the primary region is unavailable.

Key Concept

Azure Storage replication options and read-access endpoints for geo-redundant storage.

Question 627Question →

An international enterprise is planning a migration and modernization of its data tier to Azure. The migration plan requires $99.999\%$ availability for both reads and writes, sub- $10\text{ ms}$ latency at the 99th percentile, and active-active global distribution across $4$ Azure regions. The data storage tier must support an $85:15$ read-to-write ratio for the product catalog and a $20:80$ ratio for the device telemetry stream. As part of the modernization process, several disparate data systems must be migrated to Azure Cosmos DB.

Match each workload scenario to the most appropriate Azure Cosmos DB API.

Click a left item, then click its matching right item

Show answer & explanation

Answer

The correct matches pair the telemetry pipeline with the API for Cassandra, the customer profile store with the API for NoSQL, the social graph platform with the API for Gremlin, and the legacy retail catalog with the API for MongoDB.

The correct pairings align the specific workload structure, data model, and migration drivers with their designated Azure Cosmos DB API. Legacy Cassandra systems with CQL map to the API for Cassandra; new JSON document requirements map to the native API for NoSQL; graph relational structures map to the API for Gremlin; and MongoDB legacy workloads map to the API for MongoDB.

Step-by-Step Solution

Analyze the database type and migration compatibility for the legacy Cassandra workload.

The workload uses CQL (Cassandra Query Language), mapping it directly to the API for Cassandra to preserve developer tools and application logic.

Using the matching API reduces rewrite effort and risk.

Evaluate the requirement for the customer profile store.

The profile store requires JSON documents and SQL-like querying, which aligns with the native API for NoSQL.

The API for NoSQL provides optimal performance and feature support for general document-oriented workloads in Azure Cosmos DB.

Identify the data model for the social network interaction workload.

The workload requires representing entities as vertices and connections as edges, which is the graph data model supported by the API for Gremlin.

A graph model is required to efficiently query deep relationships and traversals.

Review the migration requirements for the legacy retail catalog.

The catalog is built on MongoDB, so migrating to the API for MongoDB allows compatibility with the existing MongoDB wire protocol and drivers.

This avoids code modification for MongoDB-compatible drivers and client libraries.

Key Concept

Selecting the appropriate Azure Cosmos DB API based on database model compatibility and migration source systems.

Alternative Method

Instead of evaluating by workload type first, you can filter by API capability (e.g., look for graph, column-family, and document capabilities) and map them back to the source systems.

Estimated Time:2m 0s

Question 628Question →

A financial services firm is designing an analytical data platform to query historical audit logs. The platform must meet the following requirements:
- Data volume: $45\text{ TB}$ of historical records stored in CSV format.
- Ingestion rate: Data is uploaded weekly in a single batch.
- Query latency: Data analysts run exploratory ad-hoc queries sporadically; results are expected within a few minutes.
- Resiliency: The data must survive a primary datacenter outage.
- Security: External auditors require access via Shared Access Signatures (SAS) that can be instantly revoked without rotating primary storage keys.

You need to design a query and storage solution that minimizes operational overhead and compute costs. Which solution should you recommend?

Azure Synapse Analytics dedicated SQL pools with the data loaded into dedicated database tables, stored in a Geo-Redundant Storage (GRS) Azure Data Lake Storage Gen2 account, using Shared Access Signatures (SAS) associated with a stored access policy.

Azure Synapse Analytics serverless SQL pools querying the data stored in a Locally Redundant Storage (LRS) Azure Data Lake Storage Gen2 account, using Shared Access Signatures (SAS) associated with a stored access policy.

Azure Synapse Analytics serverless SQL pools querying the data stored in a Geo-Redundant Storage (GRS) Azure Data Lake Storage Gen2 account, using Shared Access Signatures (SAS) associated with a stored access policy.

Azure Synapse Analytics serverless SQL pools querying the data stored in a Geo-Redundant Storage (GRS) Azure Data Lake Storage Gen2 account, using ad-hoc Shared Access Signatures (SAS) valid for one year without a stored access policy.

Show answer & explanation

Answer: Azure Synapse Analytics serverless SQL pools querying the data stored in a Geo-Redundant Storage (GRS) Azure Data Lake Storage Gen2 account, using Shared Access Signatures (SAS) associated with a stored access policy.

Answer

Using Azure Synapse Analytics serverless SQL pools is the most cost-effective solution for ad-hoc, sporadic querying as you are only billed for the data processed by each query. Storing the data in a Geo-Redundant Storage (GRS) account satisfies the resiliency requirement to survive a primary datacenter outage. Utilizing Shared Access Signatures (SAS) associated with a stored access policy allows the security team to instantaneously revoke access to the external auditors by modifying or deleting the policy, without needing to rotate storage account keys.

Step-by-Step Solution

Select the appropriate compute model for analytical querying.

Serverless SQL pools are selected because they charge per query (based on data processed) and do not run continuously, which minimizes costs for sporadic ad-hoc queries.

Dedicated SQL pools require provisioning persistent resources, leading to high idle costs, while serverless pools scale automatically and have zero idle cost.

Determine the storage redundancy model that survives regional outages.

Geo-Redundant Storage (GRS) is selected to replicate data to a secondary region.

Locally Redundant Storage (LRS) only replicates data within a single datacenter, failing the requirement to survive a primary datacenter outage.

Design the security token mechanism for external auditors.

Shared Access Signatures (SAS) linked to a stored access policy are selected.

Stored access policies allow immediate revocation of SAS tokens by editing or deleting the policy, avoiding the need to rotate the main storage account keys.

Key Concept

Data Integration and Analytical Storage

Question 629Question →

A financial company is designing a new event-driven transaction processing system on Azure. The system has the following requirements:
- Web APIs and background workers must scale dynamically based on the number of messages in an Azure Service Bus queue, including scaling down to zero instances.
- The background workers must support event-driven autoscaling using KEDA.
- You must run ad-hoc data reconciliation tasks that execute to completion and then terminate.
- You must minimize the administrative and operational effort required to manage the container infrastructure.
- Logs for the container workloads must be collected. For regulatory compliance, the production environment logs and test environment logs must be isolated and stored in different geographic regions.

Which two configurations should you recommend? (Select two.)

Select all that apply

Azure Container Apps for hosting the web APIs and background workers, and Azure Container Apps Jobs for running the reconciliation tasks.

Separate regional Azure Log Analytics workspaces for the production and test environment container logs.

An Azure Kubernetes Service (AKS) cluster to host the web APIs, workers, and reconciliation tasks.

A single global Azure Log Analytics workspace located in the primary region to consolidate logs from both environments.

Show answer & explanation

Answer: Azure Container Apps for hosting the web APIs and background workers, and Azure Container Apps Jobs for running the reconciliation tasks.; Separate regional Azure Log Analytics workspaces for the production and test environment container logs.

Answer

Azure Container Apps for hosting the web APIs and background workers with Azure Container Apps Jobs for running the reconciliation tasks, combined with separate regional Azure Log Analytics workspaces for the production and test environments.

The combination of Azure Container Apps and Azure Container Apps Jobs satisfies the event-driven scaling, run-to-completion, and low operational overhead requirements. Azure Container Apps manages Kubernetes orchestration and provides native KEDA scaling. Additionally, creating separate regional Log Analytics workspaces ensures that data residency and compliance rules are respected, as workspaces are regionally bound.

Step-by-Step Solution

Analyze container hosting requirements including KEDA-based scaling, scaling to zero, run-to-completion execution, and minimal administrative effort.

Determine that Azure Container Apps (ACA) fits the microservice scaling needs, and Azure Container Apps Jobs fits the run-to-completion task needs without the operational overhead of managing a Kubernetes cluster.

Azure Container Apps is a serverless platform that simplifies container deployments and manages the underlying Kubernetes orchestration for you.

Evaluate log storage compliance requirements for regional isolation.

Determine that separate regional Log Analytics workspaces are required because a single workspace is locked to one region and cannot store logs in multiple geographic locations for compliance segregation.

Log Analytics workspaces are bound to specific regions, and compliance requirements dictate data residency and isolation.

Key Concept

Selecting optimal Azure container hosting services based on scaling, lifecycle, and operational overhead requirements, combined with configuring compliant, regionally isolated monitoring architectures.

Question 630Question →

A multinational retail corporation, Contoso Logistics, is designing a hybrid identity and security strategy to integrate its on-premises Active Directory Domain Services (AD DS) with Microsoft Entra ID. The design must satisfy the following requirements:
- Minimize the on-premises infrastructure footprint and management overhead.
- Allow users to authenticate to cloud services using their on-premises passwords, even if the on-premises network or domain controllers experience an outage.
- Enforce Multi-Factor Authentication (MFA) via Conditional Access for all user logins, while preventing tenant lockout in the event of an Azure MFA service disruption.
- Ensure that administrators can activate highly privileged roles only when needed, requiring approval and justification.

Which identity and security architecture should you recommend to meet these requirements?

Configure Microsoft Entra Connect with Password Hash Synchronization (PHS). Create a Conditional Access policy requiring MFA, excluding a designated emergency access account group. Use Microsoft Entra Privileged Identity Management (PIM) to configure eligible role assignments.

Configure Microsoft Entra Connect with Active Directory Federation Services (AD FS). Create a Conditional Access policy requiring MFA, excluding a designated emergency access account group. Use Microsoft Entra Privileged Identity Management (PIM) to configure eligible role assignments.

Configure Microsoft Entra Connect with Password Hash Synchronization (PHS). Create a Conditional Access policy requiring MFA for all users with no exclusions. Use Microsoft Entra Privileged Identity Management (PIM) to configure eligible role assignments.

Show answer & explanation

Answer: Configure Microsoft Entra Connect with Password Hash Synchronization (PHS). Create a Conditional Access policy requiring MFA, excluding a designated emergency access account group. Use Microsoft Entra Privileged Identity Management (PIM) to configure eligible role assignments.

Answer

Configure Microsoft Entra Connect with Password Hash Synchronization (PHS), exclude a designated emergency access account group from the Conditional Access MFA policy, and use Microsoft Entra Privileged Identity Management (PIM) to configure eligible role assignments.

The correct architecture relies on Password Hash Synchronization (PHS), which requires the least on-premises infrastructure and ensures authentication is available even during on-premises outages. Excluding an emergency access group from the Multi-Factor Authentication (MFA) Conditional Access policy prevents tenant lockout if Azure MFA services fail. Using Microsoft Entra Privileged Identity Management (PIM) with eligible assignments ensures roles are active only when needed, requiring justification.

Step-by-Step Solution

Evaluate hybrid authentication options to minimize on-premises footprint and provide resilience during local outages.

Select Password Hash Synchronization (PHS) since it requires no extra on-premises infrastructure beyond Microsoft Entra Connect and allows cloud authentication even if on-premises domain controllers are unreachable.

Active Directory Federation Services (AD FS) requires significant on-premises infrastructure, making it unsuitable for minimizing the footprint.

Analyze Conditional Access policies for MFA and prevent lockout scenarios.

Require MFA for users but exclude emergency access (break-glass) accounts from the policy.

Excluding emergency access accounts ensures administrators can access the tenant if the Azure MFA service is experiencing an outage.

Determine the appropriate Privileged Identity Management (PIM) role assignment type to enforce just-in-time access.

Configure assignments as eligible rather than active.

Eligible assignments require users to request activation, provide justification, and undergo MFA/approval before receiving the privileges, unlike permanently active assignments.

Key Concept

Microsoft Entra ID Authentication methods, Conditional Access emergency exclusions, and Privileged Identity Management role configurations.

Estimated Time:1m 30s

Question 631Question →

An energy utility company is designing a new container-based monitoring solution on Azure. The solution must support two environments: Production and Test.

The design must satisfy the following requirements:
* The containerized workloads in Production and Test must be completely isolated from each other at the network and compute levels.
* Administrative and operational overhead for managing the container infrastructure must be minimized.
* System logs from the Production environment must be stored in a different Log Analytics workspace than the Test environment logs to comply with strict data sovereignty policies.

Which two recommendations should you include in the infrastructure design? (Select two.)

Select all that apply

Create a dedicated Log Analytics workspace for the Production environment and another dedicated Log Analytics workspace for the Test environment.

Create a single Log Analytics workspace for both environments and use custom tables to segregate the logs.

Deploy a separate Azure Container Apps environment for the Production workloads and the Test workloads.

Deploy a single Azure Container Apps environment and use separate container apps to run the Production and Test workloads.

Deploy an Azure Kubernetes Service (AKS) cluster and use namespaces to segregate the Production and Test workloads.

Show answer & explanation

Answer: Create a dedicated Log Analytics workspace for the Production environment and another dedicated Log Analytics workspace for the Test environment.; Deploy a separate Azure Container Apps environment for the Production workloads and the Test workloads.

Answer

Deploy a separate Azure Container Apps environment for the Production workloads and the Test workloads, and create a dedicated Log Analytics workspace for the Production environment and another dedicated Log Analytics workspace for the Test environment.

To satisfy the requirements of network/compute isolation and minimal administrative overhead, deploying separate Azure Container Apps environments is the best practice. Since Azure Container Apps environments write logs to a single associated Log Analytics workspace, using separate environments allows mapping Production and Test to separate, dedicated Log Analytics workspaces. This satisfies the requirement to store logs in different workspaces for compliance reasons.

Step-by-Step Solution

Evaluate the hosting options based on the operational overhead constraints.

Azure Container Apps is selected as it is a serverless platform that minimizes administrative overhead compared to managing an Azure Kubernetes Service cluster.

The requirement states that administrative and operational overhead for managing the container infrastructure must be minimized.

Analyze how to achieve complete network and compute isolation for the containerized workloads.

Separate Azure Container Apps environments are required because a single environment shares the same virtual network and underlying compute resources.

The workloads must be completely isolated at the network and compute levels.

Align the logging configuration with the environment isolation and workspace requirements.

Two dedicated Log Analytics workspaces are created and mapped to the separate Container Apps environments.

Azure Container Apps environments log to a single workspace. To segregate logs between Production and Test, separate workspaces and separate Container Apps environments are necessary.

Key Concept

Selecting container hosting services and designing isolation boundaries and logging architectures based on administrative, network, and compliance requirements.

Question 632Question →

An organization is designing a disaster recovery (DR) solution from the Azure East US region to the West US region for a critical retail application. The application consists of two virtual machine tiers:

* Web Tier: Two virtual machines named `VM-Web1` and `VM-Web2` deployed on Standard_D2s_v5 size. Each VM has a single OS disk using Standard SSD storage, with a write churn rate of $1.2\text{ MB/s}$ per disk.
* Database Tier: A single virtual machine named `VM-DB1` running SQL Server on Standard_E8s_v5 size. The VM has one OS disk and one data disk ( $512\text{ GB}$ ) containing database files. Both disks use Standard SSD storage. The data disk has an average write churn rate of $14\text{ MB/s}$ .

The organization specifies a Recovery Point Objective (RPO) of 1 hour and a Recovery Time Objective (RTO) of 2 hours for the entire application.

Which of the following actions should you include in the disaster recovery design? (Select TWO.)

Select all that apply

Replicate `VM-Web1` and `VM-Web2` to the West US region by using Azure Site Recovery.

Change the database data disk of `VM-DB1` to Premium SSD, and then replicate `VM-DB1` to the West US region by using Azure Site Recovery.

Replicate `VM-DB1` to the West US region using Azure Site Recovery with its current Standard SSD data disk configuration.

Configure Read-Access Geo-Redundant Storage (RA-GRS) to replicate the virtual machine disks directly.

Replicate `VM-DB1` to the West US region by using Azure Backup with a 1-hour backup replication interval.

Show answer & explanation

Answer: Replicate `VM-Web1` and `VM-Web2` to the West US region by using Azure Site Recovery.; Change the database data disk of `VM-DB1` to Premium SSD, and then replicate `VM-DB1` to the West US region by using Azure Site Recovery.

Answer

Replicate the web VMs using Azure Site Recovery, and upgrade the database data disk to Premium SSD before replicating the database VM using Azure Site Recovery.

The correct options recommend replicating the web tier VMs using Azure Site Recovery as-is, since their write churn (

1.2\text{ MB/s}

) is well within the

8\text{ MB/s}

limit for Standard SSD. For the database tier, the data disk's write churn (

14\text{ MB/s}

) exceeds the Standard SSD limit (

8\text{ MB/s}

), so it must be upgraded to Premium SSD (which supports up to

54\text{ MB/s}

of write churn) before configuring Azure Site Recovery.

Step-by-Step Solution

Evaluate the write churn of the web tier disks against Azure Site Recovery limits.

The web tier VMs have a write churn of

1.2\text{ MB/s}

on Standard SSD. Since the Azure Site Recovery limit for Standard SSD is

8\text{ MB/s}

, they can be replicated as-is.

To determine if the current storage configuration supports Azure Site Recovery replication for the web tier.

Evaluate the write churn of the database tier disks against Azure Site Recovery limits.

The database VM has a data disk write churn of

14\text{ MB/s}

on Standard SSD. This exceeds the Azure Site Recovery limit of

8\text{ MB/s}

for Standard SSD.

To identify replication bottlenecks or compatibility issues for the database tier.

Select the appropriate storage upgrade and replication strategy for the database tier.

Upgrading the database data disk to Premium SSD increases the Azure Site Recovery disk churn limit to

54\text{ MB/s}

, accommodating the

14\text{ MB/s}

write churn and enabling replication.

To meet the DR requirements while keeping the workload fully supported by Azure Site Recovery.

Key Concept

Azure Site Recovery VM replication disk write churn limits

Estimated Time:2m 0s

Question 633Question →

An enterprise is designing a data storage and retention strategy for three distinct datasets in Azure Blob Storage:

* Audit reports: These reports are accessed frequently for the first 30 days after generation. Between 30 and 180 days, they are accessed occasionally and must be available immediately with sub-second retrieval latency. After 180 days, they are rarely accessed, and a retrieval latency of up to 15 hours is acceptable. The reports must be deleted after 3 years ( $1095$ days).
* Transactional ledger data: This data must be stored in a write-once, read-many (WORM) state to meet strict compliance regulations. The data cannot be modified or deleted for 7 years ( $2555$ days) and is queried by an automated auditing system that requires real-time (sub-second) access.
* Temporary debug logs: These logs are generated daily and are only kept for 45 days to assist in active troubleshooting. They are rarely accessed, but when they are, a retrieval latency of up to 15 hours is acceptable.

You need to design a storage tiering and retention solution that minimizes costs while meeting all regulatory and performance requirements.

Which two configurations should you include in the design? (Select TWO)

Select all that apply

Configure a lifecycle management policy for the audit reports container to transition blobs to the Cool tier after 30 days, transition them to the Archive tier after 180 days, and delete them after 1095 days.

Configure a locked time-based retention policy on the ledger data container with a retention period of 2555 days.

Configure a lifecycle management policy for the audit reports container to transition blobs to the Archive tier after 30 days, using high-priority rehydration to satisfy the sub-second retrieval requirement.

Configure a lifecycle management policy for the temporary debug logs container to transition blobs to the Archive tier after 10 days and delete them after 45 days.

Show answer & explanation

Answer: Configure a lifecycle management policy for the audit reports container to transition blobs to the Cool tier after 30 days, transition them to the Archive tier after 180 days, and delete them after 1095 days.; Configure a locked time-based retention policy on the ledger data container with a retention period of 2555 days.

Answer

The correct configurations are to transition the audit reports through Cool and Archive tiers before deleting them, and to apply a locked time-based retention policy on the ledger data container.

The configuration transitioning the audit reports through the Cool tier and Archive tier before deleting them satisfies all latency constraints at the lowest possible cost, as the Cool tier supports sub-second access and the Archive tier handles the longer-term retrieval window. Applying a locked time-based retention policy on the ledger data container enforces the mandatory 7-year WORM state compliance, preventing any modification or deletion by any user.

Step-by-Step Solution

Analyze the audit reports requirements.

The reports need sub-second retrieval latency between 30 and 180 days (Cool tier supports this) and up to 15 hours latency after 180 days (Archive tier supports this). The 3-year deletion translates to 1095 days.

This establishes the transition timeline and targets for the lifecycle management policy of the audit reports.

Analyze the transactional ledger data requirements.

The data must be stored in a WORM state and cannot be modified or deleted for 7 years (2555 days) while maintaining sub-second latency.

This requires a locked time-based retention policy on the container. Transitioning ledger data to the Archive tier is ruled out because it violates the sub-second latency requirement.

Analyze the temporary debug logs requirements and assess early deletion fees.

Although they allow 15 hours of latency, the logs are deleted after 45 days. Transitioning them to the Archive tier violates the 180-day minimum retention threshold and incurs early deletion fees.

This confirms that the debug logs should not be transitioned to the Archive tier, rendering that option incorrect.

Key Concept

Azure Blob Storage Lifecycle Management and Container Immutability Policies

Question 634Question →

An enterprise is designing a hub-and-spoke network topology in Azure to support dynamic routing between on-premises branch offices and Azure resources. The topology consists of the following:

* A hub virtual network named `vnet-use-hub` ( $10.100.0.0/16$ ) containing:
* `GatewaySubnet` ( $10.100.0.0/24$ ) with an ExpressRoute gateway.
* `RouteServerSubnet` ( $10.100.1.0/24$ ) hosting an Azure Route Server.
* `subnet-nva` ( $10.100.2.0/24$ ) hosting a pair of SD-WAN Network Virtual Appliances (NVAs) that establish BGP sessions with the Azure Route Server.
* A spoke virtual network named `vnet-prod-spoke` ( $10.101.0.0/16$ ) containing application workloads in `subnet-app` ( $10.101.1.0/24$ ).

A virtual network peering connects `vnet-use-hub` and `vnet-prod-spoke` with gateway transit enabled on the hub side.

The design must satisfy these requirements:
* Application workloads in `subnet-app` must dynamically learn and route traffic to on-premises branch offices via the SD-WAN NVAs.
* You must minimize manual administrative effort by avoiding static user-defined routes (UDRs) in the spoke virtual network.
* Direct traffic between `vnet-prod-spoke` and the hub VNet `vnet-use-hub` must be maintained without routing through the SD-WAN NVAs to ensure optimal latency.
* The Azure Route Server must exchange routing information between the SD-WAN NVAs and the ExpressRoute gateway.

Which two actions should you include in the design?

Select all that apply

Enable branch-to-branch routing on the Azure Route Server.

Enable the 'Use the remote virtual network's gateway or Route Server' option on the peering from `vnet-prod-spoke` to `vnet-use-hub`.

Configure a User Defined Route (UDR) on `subnet-app` with the address prefix `10.100.0.0/16` and next hop type `Virtual Appliance` pointing to the SD-WAN NVAs.

Configure a User Defined Route (UDR) on `subnet-app` with the address prefix `10.101.0.0/16` and next hop type `VnetLocal`.

Enable the 'Use the remote virtual network's gateway or Route Server' option on the peering from `vnet-use-hub` to `vnet-prod-spoke`.

Show answer & explanation

Answer: Enable branch-to-branch routing on the Azure Route Server.; Enable the 'Use the remote virtual network's gateway or Route Server' option on the peering from `vnet-prod-spoke` to `vnet-use-hub`.

Answer

Enable branch-to-branch routing on the Azure Route Server, and enable the 'Use the remote virtual network's gateway or Route Server' option on the peering from the spoke virtual network to the hub virtual network.

The correct configurations are enabling branch-to-branch routing on the Azure Route Server and configuring the peering from the spoke to the hub to use the remote gateway or Route Server. Enabling branch-to-branch routing is necessary for the Azure Route Server to propagate dynamically learned routes between the ExpressRoute gateway and the SD-WAN Network Virtual Appliances (NVAs). Enabling the 'Use the remote virtual network's gateway or Route Server' option on the peering from the spoke to the hub allows the spoke virtual network to dynamically receive the routes advertised by the Route Server. Direct traffic between the spoke and the hub is maintained because local virtual network and peered virtual network system routes are prioritized over dynamic BGP routes (which typically target on-premises address spaces).

Step-by-Step Solution

Configure the virtual network peering from the spoke virtual network to the hub virtual network to allow route consumption.

Setting 'Use the remote virtual network's gateway or Route Server' (useRemoteGateways = true) on the spoke-to-hub peering enables the spoke virtual network to dynamically learn routes from the Azure Route Server in the hub.

This satisfies the requirement to dynamically propagate on-premises routes to the spoke application subnet without configuring static user-defined routes.

Enable branch-to-branch routing on the Azure Route Server.

The Route Server will propagate BGP routes between the ExpressRoute gateway and the SD-WAN Network Virtual Appliances.

This allows on-premises branch offices connected via SD-WAN and datacenters connected via ExpressRoute to exchange routing information.

Validate local VNet and peering system routes to ensure latency requirements are met.

Default system routes for the peered hub virtual network (

10.100.0.0/16

) remain active on the spoke, ensuring direct spoke-to-hub communication.

Adding a static UDR for the hub range would override the system route and direct local traffic to the NVAs, violating latency goals.

Key Concept

Dynamic routing propagation and transit path selection using Azure Route Server in a hub-and-spoke topology.

Question 635Question →

An organization hosts a multi-tier application on Azure Virtual Machines. The application VMs must upload diagnostic metrics to Azure Monitor. To comply with security policies, all outbound internet traffic from the virtual machine subnet must be blocked except for traffic destined for Azure Monitor. The design must minimize administrative overhead. Which network configuration should you recommend?

An outbound Network Security Group (NSG) rule that specifies the AzureMonitor Service Tag as the destination

An outbound Network Security Group (NSG) rule that specifies the individual IP address ranges of the Azure Monitor endpoints as the destination

A User Defined Route (UDR) that redirects all outbound traffic to a default route of 0.0.0.0/0, overriding local virtual network routes

An outbound Network Security Group (NSG) rule that specifies the Internet Service Tag as the destination, combined with a custom script to regularly block non-Monitor IP ranges

Show answer & explanation

Answer: An outbound Network Security Group (NSG) rule that specifies the AzureMonitor Service Tag as the destination

Answer

An outbound Network Security Group (NSG) rule that specifies the AzureMonitor Service Tag as the destination

Using the AzureMonitor Service Tag in an outbound Network Security Group (NSG) rule is the correct approach because it specifically permits traffic to Azure Monitor endpoints while blocking other outbound internet traffic. Azure automatically updates the IP addresses associated with the Service Tag, which satisfies the requirement to minimize administrative overhead.

Step-by-Step Solution

Identify the destination service that the application needs to communicate with.

The target service is Azure Monitor.

The VMs must upload diagnostic metrics specifically to Azure Monitor.

Evaluate the requirement of minimizing administrative overhead and avoiding tracking of IP changes.

IP tracking should be managed by Azure rather than configured manually.

Azure Service Tags automatically represent IP address prefixes for specific Azure services.

Select the appropriate Network Security Group (NSG) rule destination.

The destination should be configured with the AzureMonitor Service Tag.

Using the service tag limits outbound access to only Azure Monitor without needing manual IP lists or routes.

Key Concept

Azure Service Tags simplify NSG rule management by representing a group of IP address prefixes from a specific Azure service.

Estimated Time:1m 0s

Question 636Question →

An enterprise is designing a hub-and-spoke virtual network topology in Azure to host a multi-tier application. The architecture includes:
- A hub virtual network named `vnet-hub-core` ( $10.50.0.0/16$ ) that hosts a central Azure Firewall with a private IP address of $10.50.4.4$ .
- A spoke virtual network named `vnet-spoke-web` ( $10.60.0.0/16$ ) containing a subnet named `web-subnet` ( $10.60.1.0/24$ ).
- A spoke virtual network named `vnet-spoke-db` ( $10.70.0.0/16$ ) containing a subnet named `db-subnet` ( $10.70.1.0/24$ ).

Virtual network peering is configured between the hub and each spoke virtual network. Direct virtual network peering is not configured between the two spoke virtual networks.

You need to configure the routing to meet the following requirements:
- All traffic between `web-subnet` and `db-subnet` must be routed through the Azure Firewall for inspection.
- Traffic within each spoke virtual network must remain local and bypass the Azure Firewall.

Which two configurations should you implement?

Select all that apply

In the route table associated with `web-subnet`, add a route for

10.70.0.0/16

with a next hop type of Virtual appliance and next hop IP address

10.50.4.4

In the route table associated with `db-subnet`, add a route for

10.60.0.0/16

with a next hop type of Virtual appliance and next hop IP address

10.50.4.4

In the route table associated with `web-subnet`, add a route for

10.60.0.0/16

with a next hop type of Virtual appliance and next hop IP address

10.50.4.4

In the route table associated with the Azure Firewall subnet, add routes for

10.60.0.0/16

and

10.70.0.0/16

with a next hop type of Virtual appliance and next hop IP address

10.50.4.4

Show answer & explanation

Answer: In the route table associated with `web-subnet`, add a route for $10.70.0.0/16$ with a next hop type of Virtual appliance and next hop IP address $10.50.4.4$ .; In the route table associated with `db-subnet`, add a route for $10.60.0.0/16$ with a next hop type of Virtual appliance and next hop IP address $10.50.4.4$ .

Answer

To achieve the desired routing, associate a route table with the web subnet containing a route for the database spoke's address space (

10.70.0.0/16

) pointing to the firewall (

10.50.4.4

), and associate a route table with the database subnet containing a route for the web spoke's address space (

10.60.0.0/16

) pointing to the firewall (

10.50.4.4

To route traffic between the two spoke virtual networks through the Azure Firewall in the hub, you must define User-Defined Routes (UDRs) in the spoke subnets. Specifically, a route for the remote spoke's address space (

10.70.0.0/16

in Spoke A, and

10.60.0.0/16

in Spoke B) must point to the firewall's private IP (

10.50.4.4

) as a Virtual Appliance next hop. Because there is no direct peering between the spokes, this redirect forces transit traffic to flow through the hub firewall. The default system routes within the hub automatically handle forwarding the traffic from the firewall to the destination spoke.

Step-by-Step Solution

Identify transit routing requirements

Identify that `vnet-spoke-web` needs to reach

10.70.0.0/16

, and `vnet-spoke-db` needs to reach

10.60.0.0/16

Since peering is non-transitive, spoke-to-spoke communication through a hub NVA/Firewall requires explicit routing.

Configure spoke User-Defined Routes (UDRs)

Associate route tables with `web-subnet` and `db-subnet` pointing to the next-hop IP

10.50.4.4

(Azure Firewall).

This overrides default system routing, redirecting spoke-to-spoke transit traffic through the hub firewall.

Avoid defining local address space routes in spokes

Ensure there are no UDRs inside `vnet-spoke-web` for

10.60.0.0/16

or inside `vnet-spoke-db` for

10.70.0.0/16

This keeps local intra-VNet communication intact by relying on the default 'Local' system route.

Key Concept

Hub-and-spoke transit routing using User-Defined Routes (UDRs) and Virtual Network Peering while preserving local system routes.

Question 637Question →

A healthtech company hosts a telemedicine platform on Azure virtual machines (VMs) in the East US region and is designing a disaster recovery (DR) solution to the West US region. The platform consists of a web tier, an application tier, and a database tier. The workload profiles and metrics are as follows:

- Web and Application Tiers: Four VMs (two web, two app) using Standard SSDs, with a maximum write churn of $2\text{ MB/s}$ per VM.
- Database Tier: Two VMs running SQL Server on Windows Server using Premium SSD (P30) disks. Each database VM has one log disk with a continuous write churn of $26\text{ MB/s}$ and one data disk with a write churn of $6\text{ MB/s}$ .

Your disaster recovery design must satisfy the following business requirements:
- A Recovery Point Objective (RPO) of $4\text{ hours}$ for the web and application tiers.
- An RPO of $10\text{ seconds}$ for the database tier.
- A Recovery Time Objective (RTO) of $1\text{ hour}$ for the entire platform.

Which disaster recovery architecture should you design to meet these requirements?

Replicate the web and application tier VMs to the target region using Azure Site Recovery. Replicate the database tier by configuring SQL Server Always On availability groups with asynchronous commit to database replicas in the target region.

Replicate all virtual machines, including the database tier, to the target region using Azure Site Recovery with default replication configurations.

Replicate all virtual machines to the target region using Azure Site Recovery, configuring the database VMs to use the High Churn replication policy tier.

Configure Azure Backup to perform hourly application-consistent backups of all virtual machines, replicating the backups to a Geo-Redundant Storage vault in the target region.

Show answer & explanation

Answer: Replicate the web and application tier VMs to the target region using Azure Site Recovery. Replicate the database tier by configuring SQL Server Always On availability groups with asynchronous commit to database replicas in the target region.

Answer

The correct design uses Azure Site Recovery to replicate the low-churn web and application tiers, and SQL Server Always On availability groups with asynchronous commit to replicate the database tier. This avoids ASR's disk write churn limit, which maxes out at

20\text{ MB/s}

per Premium SSD even when using the High Churn tier, and satisfies the database tier's strict

10\text{-second}

RPO requirement.

Step-by-Step Solution

Analyze the database write churn rates against Azure Site Recovery limits.

The database log disk experiences

26\text{ MB/s}

of write churn. Standard Azure Site Recovery (ASR) supports up to

10\text{ MB/s}

per Premium SSD disk, and the High Churn policy tier supports up to

20\text{ MB/s}

per Premium SSD disk. Thus, the database's write churn exceeds ASR capacity thresholds.

To verify if ASR can support the write-heavy database workload.

Evaluate the Recovery Point Objective (RPO) requirements.

The web and application tiers require a

4\text{-hour}

RPO, which is easily achievable by ASR. The database tier requires a

10\text{-second}

RPO, which cannot be guaranteed by ASR replication intervals.

To determine if ASR replication intervals are sufficient for the database data loss threshold.

Select replication mechanisms for each tier to construct the design.

Use ASR for the web and application tiers because it meets the

4\text{-hour}

RPO and

1\text{-hour}

RTO. Use SQL Server Always On availability groups with asynchronous commit for the database tier to support both the high write churn and the

10\text{-second}

RPO.

To combine ASR and native database replication into a unified, compliant disaster recovery strategy.

Key Concept

Azure Site Recovery churn limits and database-native replication integration

Estimated Time:2m 30s

Question 638Question →

An enterprise is designing a high-availability hybrid network topology in Azure to support dynamic routing and traffic inspection. The design includes the following components:

* A hub virtual network named `vnet-hub-useast` ( $10.10.0.0/16$ ) containing an Azure Route Server in the `RouteServerSubnet` ( $10.10.1.0/24$ ) and two active-active Network Virtual Appliances (NVAs) in `subnet-nva` ( $10.10.2.0/24$ ).
* A spoke virtual network named `vnet-spoke-prod` ( $10.20.0.0/16$ ) containing `subnet-web` ( $10.20.1.0/24$ ).
* A spoke virtual network named `vnet-spoke-data` ( $10.30.0.0/16$ ) containing `subnet-db` ( $10.30.1.0/24$ ).

The NVAs establish BGP sessions with the Azure Route Server. The Route Server is configured with Branch-to-Branch enabled to exchange routes between the NVAs and an ExpressRoute Gateway in the hub.

You need to design a routing solution that meets the following requirements:
1. Subnets in `vnet-spoke-prod` and `vnet-spoke-data` must dynamically receive the on-premises routes advertised by the NVAs via BGP.
2. All spoke-to-spoke traffic (between `vnet-spoke-prod` and `vnet-spoke-data`) must be directed through the NVAs for security inspection.
3. Local traffic within `vnet-spoke-prod` (destined within $10.20.0.0/16$ ) must not be sent to the NVAs.

Which two configurations should you include in the design? (Select two.)

Select all that apply

Configure a User-Defined Route (UDR) on the route table for subnet-web with the address prefix

10.30.0.0/16

and the next hop set to the internal load balancer IP of the NVAs.

Configure virtual network peering between vnet-hub-useast and vnet-spoke-prod with 'Allow gateway transit' enabled on the hub side and 'Use the remote virtual network's gateway or Route Server' enabled on the spoke side.

Configure a User-Defined Route (UDR) on the route table for subnet-web with the address prefix

0.0.0.0/0

and the next hop set to the internal load balancer IP of the NVAs.

Configure a User-Defined Route (UDR) on the route table for subnet-web with the address prefix

10.20.0.0/16

and the next hop set to the internal load balancer IP of the NVAs.

Show answer & explanation

Answer: Configure a User-Defined Route (UDR) on the route table for subnet-web with the address prefix $10.30.0.0/16$ and the next hop set to the internal load balancer IP of the NVAs.; Configure virtual network peering between vnet-hub-useast and vnet-spoke-prod with 'Allow gateway transit' enabled on the hub side and 'Use the remote virtual network's gateway or Route Server' enabled on the spoke side.

Answer

To meet the requirements, you must configure virtual network peering with 'Allow gateway transit' enabled on the hub side and 'Use the remote virtual network's gateway or Route Server' enabled on the spoke side, and configure a User-Defined Route (UDR) on the route table for subnet-web with the address prefix 10.30.0.0/16 and the next hop set to the internal load balancer IP of the NVAs.

The design requires two key elements: first, ensuring the spoke virtual networks can dynamically receive BGP routes from the Azure Route Server. This is achieved by enabling gateway transit on the hub virtual network peering and using the remote virtual network's gateway or Route Server on the spoke side. Second, spoke-to-spoke traffic must be forced through the NVAs. Because the automatic peering system route is 10.30.0.0/16, a UDR matching that exact prefix (10.30.0.0/16) must be configured on the spoke route table. Since UDRs have priority over system routes of the same prefix length, this forces the traffic to the NVAs' internal load balancer.

Step-by-Step Solution

Determine how to propagate dynamically learned routes from the Azure Route Server in the hub to the spoke virtual networks.

Identify that default virtual network peering does not transit routes. You must enable 'Allow gateway transit' on the hub peering and 'Use the remote virtual network's gateway or Route Server' on the spoke peering.

This establishes transit capability, allowing the Azure Route Server to inject BGP routes directly into the spoke subnet route tables.

Analyze spoke-to-spoke routing behavior under default system routes.

A system-defined peering route is automatically created for 10.30.0.0/16 with the next hop set to VNet Peering.

Traffic destined for the peered spoke will use this route by default.

Evaluate the impact of using a default route (0.0.0.0/0) to inspect traffic.

A route of 0.0.0.0/0 is overridden by the more specific system route of 10.30.0.0/16 under Longest Prefix Match (LPM).

To intercept spoke-to-spoke traffic, the UDR must have a prefix equal to or more specific than the peered virtual network range.

Assess the impact of overriding the local virtual network prefix.

Overriding 10.20.0.0/16 with the next hop NVA breaks local routing and causes routing loops.

Local traffic must remain untouched to route via the default 'Virtual Network' system route.

Key Concept

Azure Route Server transit and route table precedence rules under Longest Prefix Match (LPM)

Estimated Time:3m 0s

Question 639Question →

A global retail corporation is deploying a new order processing system across the East US and West Europe Azure regions. The architecture contains two workloads:

1. An admin dashboard: A web application (HTTPS) that requires SSL termination at the edge, path-based routing (routing `/reports/*` to a specialized backend pool), and protection from SQL injection attacks.
2. A legacy sync agent: A client application that synchronizes local inventory databases using a custom TCP protocol over port 9090.

Both workloads must be highly available with automatic failover between regions.

Which routing design should you recommend to meet these requirements?

Deploy Azure Traffic Manager to route traffic for both the admin dashboard and the legacy sync agent, configuring DNS-based routing with active-active failover.

Deploy Azure Front Door to route traffic for the admin dashboard, and deploy Azure Traffic Manager to route traffic for the legacy sync agent.

Deploy Azure Front Door to route traffic for both the admin dashboard and the legacy sync agent, configuring custom routing rules to bypass HTTPS inspection for the port 9090 traffic.

Deploy a cross-region Azure Load Balancer to route traffic for both workloads, utilizing standard load balancing rules to forward port 443 and port 9090 traffic.

Show answer & explanation

Answer: Deploy Azure Front Door to route traffic for the admin dashboard, and deploy Azure Traffic Manager to route traffic for the legacy sync agent.

Answer

Deploy Azure Front Door to route traffic for the admin dashboard, and deploy Azure Traffic Manager to route traffic for the legacy sync agent.

Deploying Azure Front Door for the admin dashboard and Azure Traffic Manager for the legacy sync agent is correct. Azure Front Door is an Anycast-based Layer 7 service providing SSL termination, path-based routing, and WAF features for the HTTPS admin dashboard. Since Front Door does not support custom TCP protocols, Azure Traffic Manager (which functions at the DNS level and is protocol-agnostic) is used to provide DNS-based routing and regional failover for the legacy sync agent on port 9090.

Step-by-Step Solution

Analyze the protocol and feature requirements for the admin dashboard workload.

The workload uses HTTPS and needs SSL offloading at the edge, path-based routing, and WAF protection.

These requirements necessitate a global Layer 7 load balancer with application security integration, which points to Azure Front Door.

Analyze the protocol and port requirements for the legacy sync agent workload.

The legacy workload uses a custom TCP protocol over port 9090.

Because it uses a custom TCP protocol (non-HTTP) on an arbitrary port, Azure Front Door cannot be used. A DNS-based or Layer 4 global routing solution is required.

Evaluate combined traffic routing options to ensure all requirements and regional failover are met.

Select Azure Front Door for the HTTPS admin dashboard and Azure Traffic Manager for the legacy custom TCP agent.

This separation aligns each workload with a service that supports its protocols and required features, while providing robust cross-region failover capability.

Key Concept

Azure Front Door is a global Layer 7 load balancer that handles HTTP/HTTPS traffic with features like SSL offloading and WAF. Azure Traffic Manager is a DNS-based load balancer that operates at the DNS layer and is protocol-agnostic, making it ideal for non-HTTP/HTTPS protocols like custom TCP.

Estimated Time:2m 0s

Question 640Question →

An organization is designing a secure architecture for a cloud application. The application database layer runs on an Azure SQL Database. The application logic runs on Azure Virtual Machines (VMs) deployed in a subnet named AppSubnet within an Azure Virtual Network.

The network security requirements are:
1. Prevent all public internet access to the Azure SQL Database.
2. Allow VMs in AppSubnet to connect securely to the Azure SQL Database.
3. Restrict outbound database traffic from AppSubnet to only the required SQL database.
4. Minimize administrative effort for managing changes to IP addresses.

Which two configurations should you recommend in the design?

Select all that apply

Disable public network access on the Azure SQL logical server.

Create a private endpoint for the Azure SQL Database in the virtual network.

Create outbound Network Security Group (NSG) rules on AppSubnet using the specific public IP addresses of the Azure SQL Database instances in the region.

Configure the AppSubnet Network Security Group (NSG) to allow outbound traffic to the AzureSQL service tag and configure the Azure SQL logical server firewall to allow the public IP of the NAT Gateway associated with AppSubnet.

Show answer & explanation

Answer: Disable public network access on the Azure SQL logical server.; Create a private endpoint for the Azure SQL Database in the virtual network.

Answer

The correct configurations are to disable public network access on the Azure SQL logical server and to create a private endpoint for the Azure SQL Database in the virtual network.

Disabling public network access on the Azure SQL logical server satisfies the absolute restriction of public internet exposure. Creating a private endpoint projects the database onto a private IP address inside the virtual network. This allows the VMs in the subnet to access the database securely and lets administrators write precise NSG outbound rules targeting only that private IP.

Step-by-Step Solution

Address the requirement to prevent all public internet access to the database.

Identify that public network access must be explicitly disabled on the Azure SQL logical server settings.

This blocks all external traffic attempting to connect through the public endpoint of the database.

Address the requirement to allow secure access from VMs within the virtual network.

Deploy a Private Endpoint for the Azure SQL Database in the virtual network.

Private Link maps a private IP address from the virtual network to the database, allowing internal VMs to route traffic securely over the Microsoft backbone instead of the public internet.

Evaluate NSG and service tag options against administrative and restriction constraints.

Reject individual IP rules due to administrative overhead and reject the service tag due to over-permissiveness.

Using specific public IP rules requires frequent manual updates. The AzureSQL service tag allows traffic to all regional databases, violating the rule of least privilege.

Key Concept

Azure Private Link and Private Endpoints enable secure private access to PaaS services from within a virtual network, allowing public endpoints to be disabled and providing deterministic private IPs for granular security rules.

PreviousPage 32 / 60Next

All practice questions

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Alternative Method

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Alternative Method

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer