Design Infrastructure Solutions

360 questions

All types360 Multiple choice189 Multiple select171

An organization is designing a hub-and-spoke virtual network topology in Azure to host a multi-tier web application. The topology consists of the following components:

* A hub virtual network named `vnet-eus-hub` ( $10.100.0.0/16$ ) hosting an Azure Firewall at IP address $10.100.10.4$ .
* A production spoke virtual network named `vnet-eus-prod` ( $10.101.0.0/16$ ) peered with the hub virtual network.
* Three subnets inside `vnet-eus-prod`:
* `subnet-web` ( $10.101.1.0/24$ )
* `subnet-app` ( $10.101.2.0/24$ )
* `subnet-db` ( $10.101.3.0/24$ )

The design must satisfy the following routing requirements:
1. All outbound internet traffic from `subnet-web` must be inspected by the Azure Firewall in the hub.
2. All traffic between `subnet-web` and `subnet-app` must be inspected by the Azure Firewall in the hub.
3. Traffic between `subnet-app` and `subnet-db` must bypass the Azure Firewall and remain local within `vnet-eus-prod` to minimize latency.
4. You must minimize administrative overhead and avoid configuring redundant route rules.

Which route table configuration should you implement to meet the requirements?

Create a single route table and associate it with all three subnets. Add a route for

0.0.0.0/0

with next hop Virtual Appliance (

10.100.10.4

), and a route for

10.101.0.0/16

with next hop Virtual Appliance (

10.100.10.4

Create a route table for `subnet-web` with routes for

0.0.0.0/0

and

10.101.2.0/24

pointing to Virtual Appliance (

10.100.10.4

). Create a separate route table for `subnet-app` with a route for

10.101.1.0/24

pointing to Virtual Appliance (

10.100.10.4

). Do not associate a custom route table with `subnet-db`.

Create a single route table and associate it with all three subnets. Add a route for

0.0.0.0/0

with next hop Virtual Appliance (

10.100.10.4

Create a single route table and associate it with `subnet-web` and `subnet-app`. Add a route for

0.0.0.0/0

with next hop Virtual Appliance (

10.100.10.4

), and a route for

10.101.0.0/16

with next hop Virtual Appliance (

10.100.10.4

Show answer & explanation

Answer: Create a route table for `subnet-web` with routes for $0.0.0.0/0$ and $10.101.2.0/24$ pointing to Virtual Appliance ( $10.100.10.4$ ). Create a separate route table for `subnet-app` with a route for $10.101.1.0/24$ pointing to Virtual Appliance ( $10.100.10.4$ ). Do not associate a custom route table with `subnet-db`.

Answer

Create a route table for the web subnet with routes for

0.0.0.0/0

and the application subnet range pointing to the firewall, create a separate route table for the application subnet with a route for the web subnet range pointing to the firewall, and use default system routes for the database subnet.

The correct solution isolates the custom route tables to only the subnets that require traffic redirection, utilizing specific subnets (specifically

10.101.2.0/24

and

10.101.1.0/24

) to route traffic between the web and application tiers through the firewall. Since the database tier does not have a custom route table associated, and no

/16

route is added to the application subnet, traffic between the application and database tiers matches the default system route

10.101.0.0/16

with next hop Local. Because this system route is more specific than the default

0.0.0.0/0

route, traffic between the application and database subnets bypasses the firewall, keeping database traffic local and avoiding high latency.

Step-by-Step Solution

Analyze routing priority rules in Azure Virtual Networks.

User-Defined Routes (UDRs) take precedence over default System Routes when they have matching prefixes. When multiple routes match a destination, Azure selects the route with the Longest Prefix Match (LPM).

Understanding LPM is essential to predict where packets will be forwarded when multiple route prefixes overlap.

Evaluate the requirement for internet traffic from the web subnet.

Adding a route for

0.0.0.0/0

with next hop Virtual Appliance (

10.100.10.4

) to a route table associated with the web subnet directs all internet-bound traffic to the Azure Firewall.

Since the internet system route has a

/0

prefix, the custom

0.0.0.0/0

route overrides it.

Evaluate the requirement for web-to-application traffic.

To route web-to-app traffic through the firewall, the web subnet's route table needs a route for

10.101.2.0/24

pointing to the firewall, and the application subnet's route table needs a route for

10.101.1.0/24

pointing to the firewall.

Without these specific

/24

routes, traffic between the web and application subnets would match the default local system route (

10.101.0.0/16

-> Local) because

/16

is a longer prefix match than

0.0.0.0/0

, bypassing the firewall.

Verify database tier isolation and local routing behavior.

By keeping the database subnet on default system routes and avoiding a broad

10.101.0.0/16

UDR on the application subnet, traffic between the application subnet (

10.101.2.0/24

) and the database subnet (

10.101.3.0/24

) matches the default local route

10.101.0.0/16

with next hop Local.

This keeps database traffic local, bypassing the firewall and avoiding high latency.

Key Concept

User-Defined Routes (UDR) precedence and Longest Prefix Match (LPM) routing in Azure Virtual Networks.

Question 82Question →

You are designing a hub-and-spoke network topology in Azure. The hub virtual network, `vnet-hub-prod` ( $10.100.0.0/16$ ), contains an active Virtual Network Gateway connected to your on-premises datacenter. The spoke virtual network, `vnet-spoke-app` ( $10.101.0.0/16$ ), contains your application workloads. You configure virtual network peering between `vnet-hub-prod` and `vnet-spoke-app`. You need to ensure that the resources in `vnet-spoke-app` can communicate with the on-premises datacenter by using the gateway in `vnet-hub-prod`. Which two configurations should you perform to meet these requirements?

Select all that apply

Configure the virtual network peering on `vnet-hub-prod` to allow gateway transit.

Configure the virtual network peering on `vnet-spoke-app` to use the remote virtual network's gateways.

Add a user-defined route to the route table in `vnet-spoke-app` that overrides the system route for its own local subnet prefix to point directly to the remote gateway.

Add individual security rules in the Network Security Group (NSG) of the spoke subnets for each specific on-premises IP address instead of using the VirtualNetwork service tag.

Show answer & explanation

Answer: Configure the virtual network peering on `vnet-hub-prod` to allow gateway transit.; Configure the virtual network peering on `vnet-spoke-app` to use the remote virtual network's gateways.

Answer

To allow the spoke virtual network to use the virtual network gateway in the hub virtual network, you must configure the peering link on the hub virtual network to allow gateway transit, and configure the peering link on the spoke virtual network to use the remote virtual network's gateways.

To establish connectivity between a spoke virtual network and an on-premises network via a gateway in a peered hub, you must configure both ends of the peering link. First, the hub's peering link must be configured to allow gateway transit. Second, the spoke's peering link must be configured to use the remote virtual network's gateways. This tells Azure to route traffic from the spoke VNet to the hub's gateway.

Step-by-Step Solution

Configure the hub-side peering link settings.

Gateway transit is enabled on the peering from the hub VNet to the spoke VNet.

This permits the hub to share its gateway with the peered spoke VNet.

Configure the spoke-side peering link settings.

The option to use remote gateways is enabled on the peering from the spoke VNet to the hub VNet.

This tells the spoke VNet to route external traffic via the hub's gateway.

Key Concept

Virtual Network Gateway Transit in VNet Peering

Question 83Question →

You are designing the serverless hosting infrastructure for an enterprise application that contains two distinct workloads:

* Workload 1: An HTTP-triggered API that processes incoming vendor requests. The API must access a backend database located in a secured Azure Virtual Network (VNet). The traffic is highly intermittent, with several hours of inactivity followed by unpredictable spikes. To minimize operating costs, the solution must scale to zero instances and incur no compute charges when idle.
* Workload 2: A queue-triggered background job that performs daily inventory synchronization. Each execution takes approximately 18 minutes to complete. The job must run on a serverless compute model that scales to zero when the queue is empty, and it must not experience timeout failures.

Which two hosting plans should you recommend to meet the requirements for both workloads? (Select two.)

Select all that apply

Azure Functions Flex Consumption plan for Workload 1

Azure Functions Consumption plan for Workload 1

Azure Kubernetes Service (AKS) for Workload 1

Azure Functions Flex Consumption plan for Workload 2

Azure Functions Consumption plan for Workload 2

Azure App Service Dedicated plan (Premium v3 tier) for Workload 2

Show answer & explanation

Answer: Azure Functions Flex Consumption plan for Workload 1; Azure Functions Flex Consumption plan for Workload 2

Answer

The correct hosting plans are the Azure Functions Flex Consumption plan for Workload 1 and the Azure Functions Flex Consumption plan for Workload 2.

The correct plans are the Azure Functions Flex Consumption plan for Workload 1 and the Azure Functions Flex Consumption plan for Workload 2. For Workload 1, the Flex Consumption plan provides native virtual network integration without any baseline instance charge, scaling down to zero cost during idle periods. For Workload 2, the Flex Consumption plan supports unbounded execution timeouts for queue-triggered functions (configured via host.json) and scales down to zero when the queue is empty, ensuring the 18-minute run completes without timeout errors and costs nothing when idle.

Step-by-Step Solution

Analyze Workload 1 requirements for outbound network connectivity and idle pricing behavior.

Workload 1 needs native outbound VNet integration and must scale to zero compute instances with zero idle costs. The standard Consumption plan is ruled out because it lacks VNet support. The Premium plan and Dedicated plans are ruled out because they incur baseline charges even when idle. The Flex Consumption plan supports native VNet integration and scales to zero cost when idle.

Ensures the database can be reached securely without incurring unnecessary infrastructure costs during idle periods.

Analyze Workload 2 requirements for execution timeout limits and scaling capabilities.

Workload 2 runs a daily batch job that requires 18 minutes. The standard Consumption plan has a strict 10-minute timeout limit, which would cause execution failure. The Premium and Dedicated plans can run for 18 minutes but charge continuously, violating the idle cost requirement. The Flex Consumption plan allows unbounded execution limits for non-HTTP triggers and scales to zero when no messages are present.

Ensures the 18-minute batch job executes successfully without timing out and only incurs billing during runtime.

Select the correct combination of options representing Flex Consumption for both Workload 1 and Workload 2.

Options representing the Azure Functions Flex Consumption plan for Workload 1 and Workload 2 are selected.

Both workloads achieve their required functional constraints at the lowest cost point using the Flex Consumption tier.

Key Concept

Azure Functions hosting plan selection based on virtual network integration, execution limits, and scale-to-zero billing behavior.

Question 84Question →

An organization is designing a hub-and-spoke network topology in Azure. The hub virtual network, `vnet-hub-core` (address space: $10.1.0.0/16$ ), hosts a central network virtual appliance (NVA) at IP address $10.1.1.4$ that provides firewall and inspection services. The spoke virtual network, `vnet-spoke-data` (address space: $10.2.0.0/16$ ), contains two subnets: `snet-db` ( $10.2.1.0/24$ ) hosting database servers, and `snet-app` ( $10.2.2.0/24$ ) hosting application servers. The networks are connected via virtual network peering.

The security policy requires that all outbound internet traffic from the database servers in `snet-db` must be inspected by the hub NVA. However, database servers must communicate directly with application servers in `snet-app` within the same virtual network without routing through the hub NVA, minimizing latency and transaction costs.

To achieve this configuration, a custom route table will be associated with the `snet-db` subnet. Which route configuration should be added to the route table?

A route for

0.0.0.0/0

with the Next Hop Type set to Virtual Appliance and the Next Hop Address set to

10.1.1.4

A route for

10.2.0.0/16

with the Next Hop Type set to Virtual Appliance and the Next Hop Address set to

10.1.1.4

, and a default route for

0.0.0.0/0

to the Internet.

Separate routes for each individual public IP address range of the internet destinations with the Next Hop Type set to Virtual Appliance and the Next Hop Address set to

10.1.1.4

A route for

0.0.0.0/0

with the Next Hop Type set to Virtual Appliance pointing to a Basic Load Balancer that distributes traffic to the NVA instances.

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 Address set to $10.1.1.4$ .

Answer

Configure a single route for

0.0.0.0/0

with the Next Hop Type set to Virtual Appliance and the Next Hop Address set to

10.1.1.4

The correct approach is to add a default route for

0.0.0.0/0

pointing to the NVA's IP address. Azure Virtual Network routing uses the Longest Prefix Match (LPM) rule. The system-defined route for the spoke virtual network is

10.2.0.0/16

(Virtual Network). Because the /16 prefix is more specific than the /0 prefix, traffic destined for the local application subnet (

10.2.2.0/24

) will match the system route and bypass the NVA. Traffic destined for the internet, which does not match the local prefix, will fall back to the

0.0.0.0/0

route and go to the NVA.

Step-by-Step Solution

Determine the destination of the traffic that requires custom routing.

Outbound internet traffic corresponds to the address prefix

0.0.0.0/0

The requirement specifies that only traffic destined for the internet must be inspected by the hub NVA.

Analyze how Azure routing matches IP addresses under default settings.

Azure uses Longest Prefix Match (LPM). The local virtual network has a system route for

10.2.0.0/16

LPM ensures that the route with the most specific prefix is selected to forward the packet.

Evaluate the interaction between the system route and the new user-defined route.

Traffic to

10.2.2.0/24

matches the

10.2.0.0/16

route (prefix length /16) instead of

0.0.0.0/0

(prefix length /0).

Since the local virtual network route prefix (/16) is longer than the default route prefix (/0), local traffic stays within the VNet and bypasses the NVA, satisfying both requirements.

Key Concept

Longest Prefix Match in Azure Routing

Estimated Time:2m 0s

Question 85Question →

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 86Question →

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 87Question →

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 88Question →

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 89Question →

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 90Question →

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 91Question →

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 92Question →

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 93Question →

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 94Question →

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 95Question →

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.

Question 96Question →

An automotive manufacturing corporation is designing a container-based telemetry and diagnostics platform on Azure. The platform will be deployed across two European regions. The design must meet the following requirements:
- A set of internal REST APIs must process incoming vehicle diagnostics data.
- A background analytics engine must process messages from an Azure Service Bus queue and scale to zero when no messages are present.
- A third-party security agent must run as a privileged DaemonSet on every container host node to inspect kernel-level system calls.
- Telemetry and logs collected from the workloads in each region must be isolated and stored only within that specific region to meet strict local data residency compliance.

You need to recommend the container hosting and monitoring architecture.

Which solution should you recommend?

Deploy Azure Kubernetes Service (AKS) in both regions with Kubernetes Event-driven Autoscaling (KEDA) configured for the background analytics engine. Configure a separate Azure Log Analytics workspace in each region to collect and store logs locally.

Deploy Azure Container Apps in both regions, running the APIs as replica apps and the background analytics engine as Azure Container Apps Jobs configured with Service Bus scaling rules. Configure a separate Azure Log Analytics workspace in each region to collect logs.

Deploy Azure Kubernetes Service (AKS) in both regions with Kubernetes Event-driven Autoscaling (KEDA) configured for the background analytics engine. Configure a single centralized Azure Log Analytics workspace to aggregate all logs from both regions to simplify monitoring administration.

Deploy Azure Container Instances (ACI) to host the REST APIs in a container group in both regions, and use Azure Functions on a Consumption plan to run the background analytics engine. Configure a single centralized Azure Log Analytics workspace for all logs.

Show answer & explanation

Answer: Deploy Azure Kubernetes Service (AKS) in both regions with Kubernetes Event-driven Autoscaling (KEDA) configured for the background analytics engine. Configure a separate Azure Log Analytics workspace in each region to collect and store logs locally.

Answer

The correct solution recommends Azure Kubernetes Service (AKS) because running a privileged security agent as a DaemonSet to inspect host-level kernel calls requires access to the underlying VM host nodes, which is supported by AKS but not by serverless container environments like Azure Container Apps. The solution uses KEDA within AKS to natively support event-driven auto-scaling to zero based on Azure Service Bus metrics. To comply with strict regional data isolation rules, the architecture deploys separate Log Analytics workspaces in each region to ensure telemetry data is stored within its local geographic boundary.

Step-by-Step Solution

Analyze the container node access requirement.

The security policy requires a third-party security agent to run as a DaemonSet to inspect kernel-level system calls on container host nodes.

This requirement indicates that the hosting platform must expose access to the underlying virtual machine host nodes. Serverless container offerings like Azure Container Apps and Azure Container Instances abstract host nodes away and do not support DaemonSets or kernel-level inspection.

Select the appropriate container hosting service.

Azure Kubernetes Service (AKS) is selected because it provides full control over the node configuration and natively supports DaemonSets.

AKS allows deploying DaemonSets onto the worker nodes to run security agents directly on each VM host, satisfying the security constraint.

Evaluate the scaling mechanism for the queue-based worker.

Configure Kubernetes Event-driven Autoscaling (KEDA) on the AKS clusters to scale the background pods based on Service Bus queue metrics.

KEDA allows Kubernetes workloads to scale to zero based on external event sources, meeting the requirement to scale to zero when no Service Bus messages are present.

Determine the monitoring and compliance architecture.

Deploy a separate Log Analytics workspace in each European region and route regional cluster logs to their respective local workspaces.

A single centralized Log Analytics workspace would aggregate data across regional boundaries, which violates the strict data residency and isolation compliance requirements.

Key Concept

Selecting Azure Kubernetes Service (AKS) vs. Azure Container Apps based on node-level control requirements, combined with regional log isolation design.

Estimated Time:2m 30s

Question 97Question →

A manufacturing company is designing a container-based quality control system on Azure. The system will run image classification models on images uploaded by factory cameras. The workloads have the following requirements:
- Scale up rapidly in response to a sudden influx of images uploaded to an Azure Blob Storage container.
- Scale down to zero when there are no images to process to minimize idle compute costs.
- Support event-driven scaling using KEDA without requiring the team to manage Kubernetes APIs, node pools, or cluster upgrades.

Which compute solution should you recommend?

Azure Container Apps

Azure Kubernetes Service (AKS)

Azure Container Instances

Azure App Service (Linux)

Show answer & explanation

Answer: Azure Container Apps

Answer

Azure Container Apps

Azure Container Apps is the recommended solution because it is a serverless container hosting service designed for microservices and event-driven applications. It supports native autoscaling using KEDA, allowing containers to scale to zero when idle, and manages all underlying Kubernetes infrastructure, APIs, and upgrades, thereby minimizing administrative effort.

Step-by-Step Solution

Analyze the scaling and infrastructure management requirements.

The solution requires rapid scaling based on events (KEDA), scaling down to zero, and minimized administrative overhead.

This rules out solutions that require managing cluster infrastructure or lack native event-driven scaling mechanisms.

Compare candidate Azure container hosting services.

Azure Container Apps is fully managed, serverless, natively supports KEDA, and scales to zero. Azure Kubernetes Service (AKS) requires node and cluster administration. Azure Container Instances (ACI) lacks native KEDA autoscaling.

Choosing the service that balances KEDA scaling with low management overhead is key to meeting the design requirements.

Key Concept

Azure Container Apps provides a serverless platform for containerized applications, enabling KEDA-driven scaling and eliminating Kubernetes cluster management overhead.

Question 98Question →

An organization is designing a serverless backend for an enterprise batch import system. The system must process files uploaded to an Azure Blob Storage container. The architectural design must satisfy the following technical constraints:

- Execution Time: The file processing logic is single-threaded and can take up to 15 minutes to complete for large payloads.
- Network Isolation: The compute resource must securely access an Azure SQL Database and storage accounts via private endpoints within an Azure Virtual Network (VNet).
- Cost Efficiency: The compute resource must automatically scale down to zero instances when there are no files to process, ensuring zero billing during idle periods.
- Operational Overhead: Minimize administrative overhead by avoiding the need to configure, build, or deploy custom Docker container images or manage container registries.

Which Azure compute hosting option should you recommend to meet these requirements?

Azure Functions on a Consumption plan

Azure Functions on an Elastic Premium plan

Azure Functions on a Flex Consumption plan

Azure Kubernetes Service (AKS) with KEDA

Show answer & explanation

Answer: Azure Functions on a Flex Consumption plan

Answer

Azure Functions on a Flex Consumption plan

The correct option is the Azure Functions Flex Consumption plan. It supports fast virtual network integration through subnet delegation, scales to zero instances when idle to eliminate cold-start costs during inactive periods, allows configuring the execution duration timeout up to 30 minutes, and offers a code-first deployment path that avoids containerization overhead.

Step-by-Step Solution

Evaluate the execution duration limit constraint.

The file processing tasks can take up to 15 minutes. This immediately rules out the standard Azure Functions Consumption plan, which has a hard maximum timeout of 10 minutes.

Choosing a plan that cannot support the maximum processing time will result in premature execution failures.

Evaluate the network isolation constraint.

The solution requires secure access to resources using private endpoints inside an Azure Virtual Network (VNet).

This rules out the standard Consumption plan as it lacks VNet integration support, but Elastic Premium, Flex Consumption, and AKS options remain viable.

Evaluate the cost constraint of scaling to zero billing during idle periods.

The compute hosting plan must scale to zero instances when idle to ensure no compute charges.

This rules out the Elastic Premium plan because it requires at least one active, pre-warmed instance, leading to continuous charges regardless of usage.

Evaluate the operational overhead and container management constraint.

The architecture must avoid container management, registry management, and custom Dockerfile creation.

This rules out Azure Kubernetes Service (AKS) with KEDA, as it introduces substantial containerization and cluster administration overhead.

Confirm the capabilities of the remaining option.

Azure Functions on a Flex Consumption plan natively supports up to 30-minute execution limits, fast subnet delegation VNet integration, scales down to zero instances when inactive, and allows code-first deployment without custom container images.

This matches all specific constraints of the scenario.

Key Concept

Selecting the optimal Azure Functions plan based on execution limits, virtual network integration, scale-to-zero capabilities, and administrative overhead.

Question 99Question →

Your company has an on-premises datacenter connected to an Azure Virtual Network (VNet) via a site-to-site VPN. You are designing a secure private access solution for a business-critical application running on virtual machines in the VNet. The application needs to connect to an Azure SQL Database. You must meet the following requirements:
- The Azure SQL Database must not accept connections from the public internet.
- The virtual machines must access the database using private IP addresses.
- On-premises database administrators must be able to manage the database using private IP addresses.
- On-premises DNS servers must resolve the database FQDN to its private IP address.
- Administrative overhead for security rule maintenance and DNS routing must be minimized.

Which network security design should you recommend?

Deploy a Private Endpoint for the Azure SQL Database. Configure an Azure DNS Private Resolver in the VNet, and set up conditional forwarding on the on-premises DNS servers to route database FQDN queries to the resolver's inbound endpoint. Apply a Network Security Group (NSG) utilizing the SQL Service Tag to secure database traffic.

Deploy a Private Endpoint for the Azure SQL Database. Configure a DNS forwarder VM in Azure to resolve the database FQDN. Apply a Network Security Group (NSG) on the virtual machine subnet containing manual outbound rules for each individual public IP address block of the regional Azure SQL Database gateway endpoints.

Deploy a Service Endpoint for the Azure SQL Database. Configure a User-Defined Route (UDR) on the virtual machine subnet that routes all database traffic to a virtual appliance, and configure a second overlapping route for the

0.0.0.0/0

destination to override system-defined routes for the database connection.

Deploy a Private Endpoint for the Azure SQL Database. Place a Basic Load Balancer in the VNet to distribute traffic to the private endpoint. Associate a Standard SKU Public IP address with the load balancer to allow secure remote administration from the on-premises environment.

Show answer & explanation

Answer: Deploy a Private Endpoint for the Azure SQL Database. Configure an Azure DNS Private Resolver in the VNet, and set up conditional forwarding on the on-premises DNS servers to route database FQDN queries to the resolver's inbound endpoint. Apply a Network Security Group (NSG) utilizing the SQL Service Tag to secure database traffic.

Answer

Deploy a Private Endpoint for the Azure SQL Database, configure an Azure DNS Private Resolver with conditional forwarding from on-premises DNS servers, and apply a Network Security Group utilizing the SQL Service Tag.

The correct answer provides a robust network security and private access design. A Private Endpoint ensures that the Azure SQL Database is only accessible via a private IP address, completely blocking public access. Deploying an Azure DNS Private Resolver allows on-premises DNS servers to forward queries to its inbound endpoint, ensuring on-premises clients can resolve the private IP address of the database. Finally, utilizing the SQL Service Tag within the Network Security Group (NSG) restricts outbound database traffic while avoiding the need to manually update rules when IP addresses change, minimizing administrative overhead.

Step-by-Step Solution

Select Private Endpoint to satisfy private access and disable public access.

The Azure SQL Database is assigned a private IP address within the VNet, and public internet access can be completely disabled.

Meets the security requirements for private IP access and zero public internet exposure.

Deploy Azure DNS Private Resolver to enable hybrid DNS resolution.

On-premises DNS servers can use conditional forwarding to target the resolver's inbound endpoint to resolve the database FQDN to its private IP.

Provides seamless DNS resolution across hybrid connections without the administrative overhead of deploying and patching DNS forwarder VMs.

Use Service Tags in Network Security Groups (NSGs) for outbound control.

The NSG uses the SQL Service Tag rather than manually configured IP blocks.

Minimizes administrative overhead since Azure automatically maintains the IP address ranges associated with the Service Tag.

Key Concept

Designing secure hybrid name resolution and private access for Azure PaaS services using Private Endpoints and Azure DNS Private Resolver.

Estimated Time:2m 0s

Question 100Question →

Your company has an Azure environment with a hub virtual network named `vnet-hub-prod` ( $10.10.0.0/16$ ) that contains a Virtual Network Gateway, and a spoke virtual network named `vnet-spoke-app` ( $10.20.0.0/16$ ). You configure Virtual Network Peering between `vnet-hub-prod` and `vnet-spoke-app`. You need to ensure that virtual machines in `vnet-spoke-app` can access your on-premises network through the gateway in `vnet-hub-prod`. Which two configuration settings should you select? (Select two.)

Select all that apply

On the peering configuration from vnet-hub-prod to vnet-spoke-app, select 'Use this virtual network's gateway or Route Server'.

On the peering configuration from vnet-spoke-app to vnet-hub-prod, select 'Use the remote virtual network's gateway or Route Server'.

Create a User Defined Route (UDR) in vnet-spoke-app that redirects the subnet's local traffic (

10.20.0.0/16

) to the gateway in vnet-hub-prod.

Create a User Defined Route (UDR) in vnet-hub-prod that routes traffic destined for vnet-spoke-app (

10.20.0.0/16

) to the Virtual Network Gateway.

Show answer & explanation

Answer: On the peering configuration from vnet-hub-prod to vnet-spoke-app, select 'Use this virtual network's gateway or Route Server'.; On the peering configuration from vnet-spoke-app to vnet-hub-prod, select 'Use the remote virtual network's gateway or Route Server'.

Answer

On the peering configuration from vnet-hub-prod to vnet-spoke-app, select 'Use this virtual network's gateway or Route Server', and on the peering configuration from vnet-spoke-app to vnet-hub-prod, select 'Use the remote virtual network's gateway or Route Server'.

To enable gateway transit in Azure Virtual Network Peering, you must configure both ends of the peering connection. In the hub virtual network (which contains the gateway), the peering to the spoke must be configured with 'Use this virtual network's gateway or Route Server' to allow the gateway to be shared. In the spoke virtual network, the peering to the hub must be configured with 'Use the remote virtual network's gateway or Route Server' to route outbound traffic through the remote gateway.

Step-by-Step Solution

Configure the hub-to-spoke peering direction.

The peering configuration from vnet-hub-prod to vnet-spoke-app has 'Use this virtual network's gateway or Route Server' enabled.

This registers the hub's gateway as shareable with the peered spoke virtual network.

Configure the spoke-to-hub peering direction.

The peering configuration from vnet-spoke-app to vnet-hub-prod has 'Use the remote virtual network's gateway or Route Server' enabled.

This allows resources in the spoke virtual network to send traffic destined for on-premises through the hub's gateway.

Key Concept

Virtual Network Peering Gateway Transit allows peered virtual networks to share a VPN or ExpressRoute gateway, eliminating the need to deploy gateways in every spoke virtual network.

Estimated Time:1m 0s

PreviousPage 5 / 18Next

Design Infrastructure Solutions

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

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution