Design Infrastructure Solutions

360 questions

All types360 Multiple choice189 Multiple select171

Your company needs to host a serverless API endpoint that generates PDF reports. Each PDF generation request is CPU-intensive and takes up to 12 minutes to complete. The solution must scale dynamically and minimize administrative overhead. Which hosting option should you recommend?

Azure Functions on a Premium plan

Azure Functions on a Consumption plan

Azure Kubernetes Service (AKS)

Azure Virtual Machines scale set using Spot VMs

Show answer & explanation

Answer: Azure Functions on a Premium plan

Answer

Azure Functions on a Premium plan

Azure Functions Premium plan provides serverless scaling and low administrative overhead while allowing execution durations up to 30 minutes (or unbounded), which easily accommodates the 12-minute requirement.

Step-by-Step Solution

Identify the execution duration requirement.

The requirement is 12 minutes of execution time.

Azure Functions Consumption plan has a 10-minute maximum limit, which rules it out.

Evaluate the administrative overhead constraints.

The solution must minimize administrative overhead and scale dynamically.

This rules out Azure Kubernetes Service (AKS) due to its high management complexity.

Evaluate workload reliability requirements.

API requests must run to completion reliably.

This rules out Spot VMs because they are subject to sudden eviction.

Key Concept

Selecting the appropriate serverless compute hosting model based on execution time limits, management overhead, and reliability.

Question 62Question →

A medical diagnostics company is designing a container-based data processing solution on Azure. The solution will process patient telemetry records from multiple regions. The solution must satisfy the following requirements:
- The data processing tasks are short-lived, containerized workloads that run to completion and execute only when new telemetry records arrive in an Azure Service Bus queue.
- The compute infrastructure must automatically scale to zero when the queue is empty, and scale out dynamically based on the queue depth using Kubernetes Event-driven Autoscaling (KEDA).
- Administrative overhead associated with managing virtual machines, orchestrator nodes, and host patching must be minimized.
- Compliance regulations dictate that patient telemetry logs must be stored and isolated within their respective geographical regions (Europe and North America).

Which two configurations should you include in the design?

Select all that apply

Azure Container Apps Jobs to host and execute the event-driven data processing tasks.

Two separate Log Analytics workspaces, one deployed in Europe and one in North America, to collect and isolate regional telemetry logs.

An Azure Kubernetes Service (AKS) cluster configured with the KEDA add-on to run the processing tasks.

A single centralized Log Analytics workspace configured with table-level Access Control Lists (ACLs) to store all telemetry logs.

Show answer & explanation

Answer: Azure Container Apps Jobs to host and execute the event-driven data processing tasks.; Two separate Log Analytics workspaces, one deployed in Europe and one in North America, to collect and isolate regional telemetry logs.

Answer

The design should include Azure Container Apps Jobs to run the event-driven data processing tasks, and two separate Log Analytics workspaces (one in Europe and one in North America) to meet regional data sovereignty and isolation requirements.

The solution requires a serverless compute platform that runs containerized, short-lived, event-driven tasks to completion while minimizing operational overhead. Azure Container Apps Jobs natively support KEDA scaling, scale to zero, and offload host management. Additionally, regional data sovereignty rules require logs to be physically isolated and stored within their respective boundaries, necessitating two separate Log Analytics workspaces (one in Europe and one in North America).

Step-by-Step Solution

Evaluate the compute options based on workload pattern and operational overhead constraints.

Identify that the workloads are short-lived, containerized tasks that run to completion and require KEDA. Azure Container Apps Jobs provide serverless execution with native KEDA triggers, eliminating node-level management compared to Azure Kubernetes Service (AKS).

This step eliminates options that introduce unnecessary management overhead like AKS.

Analyze the logging and regulatory requirements for data sovereignty.

Determine that telemetry logs must be physically stored and isolated in separate jurisdictions (Europe and North America). This requires deploying regional Log Analytics workspaces rather than a centralized one.

This step ensures compliance with data residency and sovereignty requirements.

Key Concept

Selecting serverless container services (Azure Container Apps Jobs) over full Kubernetes clusters (AKS) to reduce operational overhead for event-driven, short-lived tasks, and designing regional Log Analytics workspaces to satisfy regional data residency and compliance rules.

Estimated Time:3m 0s

Question 63Question →

An administrator designs a virtual network named `vnet-corp-ops` with the address space $192.168.0.0/16$ . The virtual network contains a subnet named `snet-application` ( $192.168.1.0/24$ ) and a security subnet named `snet-security` ( $192.168.2.0/24$ ). A network virtual appliance (NVA) is deployed in `snet-security` with the IP address $192.168.2.4$ .

To inspect internal traffic, the administrator creates a route table and associates it with `snet-application`. The route table contains a user-defined route for the prefix $192.168.0.0/16$ with a next hop type of Virtual Appliance and the next hop IP address set to $192.168.2.4$ .

How will Azure route traffic sent from a virtual machine in `snet-application` to a destination IP address of $192.168.3.10$ ?

The traffic is forwarded to the network virtual appliance at

192.168.2.4

The traffic is routed directly to

192.168.3.10

because default system routes for local virtual network traffic take precedence over user-defined routes.

The traffic is dropped by Azure because forwarding traffic back into the virtual network via a custom route is blocked by default.

The traffic is routed directly to

192.168.3.10

because the system route is considered a more specific match than the user-defined route.

Show answer & explanation

Answer: The traffic is forwarded to the network virtual appliance at $192.168.2.4$ .

Answer

The traffic is forwarded to the network virtual appliance at

192.168.2.4

The correct answer is correct because Azure routing rules dictate that when two routes have the same prefix length, a user-defined route takes precedence over the default system route. Therefore, the custom route directing traffic to the virtual appliance at

192.168.2.4

is selected.

Step-by-Step Solution

Identify the destination IP and find all matching routes in the route table associated with snet-application.

The destination IP

192.168.3.10

matches both the default system route for the virtual network (

192.168.0.0/16

) and the user-defined route (

192.168.0.0/16

Azure evaluates routes by comparing the destination IP against the prefixes of all active routes.

Apply the longest prefix match rule to determine if one route is more specific.

Both matching routes have the same prefix length of

/16

If one route had a longer prefix, it would be selected immediately. Since they are identical, prefix length does not break the tie.

Apply Azure route source priority rules to resolve identical prefix matches.

The user-defined route is selected over the default system route.

Azure assigns higher priority to user-defined routes than to default system routes when prefix lengths are identical.

Key Concept

User-defined route precedence over default system routes

Question 64Question →

You are designing the hosting infrastructure for a new, simple containerized web application. The application needs to scale dynamically based on incoming HTTP traffic, and the development team wants to minimize operational overhead. Which two Azure compute options should you recommend? (Select two.)

Select all that apply

Azure Container Apps

Azure App Service (Web App for Containers)

Azure Kubernetes Service (AKS)

Azure Functions on a Consumption plan

Show answer & explanation

Answer: Azure Container Apps; Azure App Service (Web App for Containers)

Answer

Azure Container Apps and Azure App Service (Web App for Containers) are the correct options to host the application.

Azure Container Apps and Azure App Service (Web App for Containers) are the correct options because they are fully managed platform offerings that require minimal operational overhead and support automatic, dynamic scaling based on HTTP traffic. This matches the requirements of hosting a simple containerized web application with low administrative effort.

Step-by-Step Solution

Analyze the application hosting requirements.

The application is a simple, single containerized web app requiring dynamic scaling based on HTTP traffic and minimal operational overhead.

This establishes the criteria for evaluating the compute services.

Evaluate the overhead and capabilities of each service option.

Azure Container Apps and Azure App Service are both fully managed PaaS/serverless offerings that require minimal configuration and automatically handle HTTP-based scaling. Azure Kubernetes Service (AKS) introduces complex Kubernetes cluster management overhead. Azure Functions on a Consumption plan is designed for short-lived, event-driven functions and has execution timeout limits that make it unsuitable for persistent web applications.

This filters out high-overhead and functionally constrained options.

Select the two options that best match the criteria.

Azure Container Apps and Azure App Service (Web App for Containers) are selected.

Both satisfy the operational simplicity and HTTP-based scaling requirements.

Key Concept

Selecting appropriate managed container hosting options in Azure to minimize operational overhead.

Question 65Question →

An enterprise designs a virtual network named `vnet-sea-prod` ( $172.20.0.0/16$ ) to host a two-tier application. The virtual network contains the following subnets:

* `snet-app` ( $172.20.1.0/24$ ) containing application servers
* `snet-data` ( $172.20.2.0/24$ ) containing database servers
* `snet-shared` ( $172.20.10.0/24$ ) containing a virtual firewall appliance with the IP address $172.20.10.4$

The company's security policy requires that all traffic originating from the application servers in `snet-app` and destined for the database servers in `snet-data` must be inspected by the firewall. However, virtual machines within `snet-app` must be able to communicate directly with each other without routing through the firewall.

You need to design a routing solution that meets these requirements.

Which route should you add to a route table associated with `snet-app`?

A route with the destination prefix

172.20.2.0/24

and next hop type Virtual appliance pointing to

172.20.10.4

A route with the destination prefix

172.20.0.0/16

and next hop type Virtual appliance pointing to

172.20.10.4

A route with the destination prefix

0.0.0.0/0

and next hop type Virtual appliance pointing to

172.20.10.4

A route with the destination prefix

172.20.1.0/24

and next hop type Virtual appliance pointing to

172.20.10.4

Show answer & explanation

Answer: A route with the destination prefix $172.20.2.0/24$ and next hop type Virtual appliance pointing to $172.20.10.4$

Answer

A route with the destination prefix

172.20.2.0/24

and next hop type Virtual appliance pointing to

172.20.10.4

The correct route uses the destination prefix

172.20.2.0/24

. Because this prefix is more specific than the default local virtual network route of

172.20.0.0/16

, traffic from the application subnet destined for the database subnet will be directed to the firewall. Since there is no user-defined route for the application subnet itself (

172.20.1.0/24

), traffic between servers in the same subnet will continue to use the system route and flow directly without hitting the firewall, satisfying both requirements.

Step-by-Step Solution

Analyze Azure's routing evaluation order.

Azure routes traffic based on the Longest Prefix Match (LPM) algorithm and evaluates User-Defined Routes (UDRs) before default system routes of the same prefix length.

To determine how traffic will flow, we must identify the most specific prefix match in the route table for each target destination.

Define the rule for traffic going from the application subnet to the database subnet.

A route targeting

172.20.2.0/24

with the next hop of the firewall (

172.20.10.4

) is more specific than the default

172.20.0.0/16

system route. Traffic to the database subnet will successfully go through the firewall.

This satisfies the security requirement to inspect app-to-database traffic.

Verify that intra-subnet communication is not impacted.

Intra-subnet traffic (destined for

172.20.1.0/24

) will not match the new

172.20.2.0/24

route. Instead, it falls back to the default local system route (

172.20.0.0/16

-> Local), routing directly within the subnet.

This satisfies the requirement that VMs in the application subnet must communicate directly without traversing the firewall.

Key Concept

Azure User-Defined Routes (UDR) override system routes and are evaluated using Longest Prefix Match (LPM). To steer traffic between specific subnets without disrupting intra-subnet traffic, UDRs should specify the exact destination subnet range rather than the entire virtual network prefix.

Question 66Question →

An enterprise is designing a hub-and-spoke virtual network topology in Azure. The hub virtual network, `vnet-weur-hub` (address space: $10.10.0.0/16$ ), contains:
- An internal Azure Standard Load Balancer with a frontend IP address of $10.10.1.100$ that balances traffic across an active-active pair of network virtual appliances (NVAs).
- An Azure ExpressRoute Gateway in the `GatewaySubnet` ( $10.10.3.0/24$ ) connected to an on-premises network that advertises the IP prefix $172.16.0.0/12$ .

The spoke virtual network, `vnet-prod-spoke` (address space: $10.20.0.0/16$ ), is peered with `vnet-weur-hub` with gateway transit enabled on the hub and remote gateway usage enabled on the spoke. The spoke virtual network contains two subnets:
- `snet-web` ( $10.20.1.0/24$ )
- `snet-data` ( $10.20.2.0/24$ )

You need to design a routing solution for the virtual machines in `snet-web` to satisfy the following requirements:
- All outbound traffic to the internet must pass through the NVAs for security inspection.
- Traffic to the on-premises network must bypass the NVAs and route directly through the ExpressRoute Gateway.
- Traffic between `snet-web` and `snet-data` must remain internal to the spoke virtual network and must not transit the hub or the NVAs.
- The design must minimize administrative overhead and avoid configuring redundant route entries.

Which three configuration actions should you include in the design? (Select three.)

Select all that apply

Create a custom route table and associate it with `snet-web`.

In the custom route table, add a route for

0.0.0.0/0

with the next hop type of Virtual Appliance and the next hop IP address set to

10.10.1.100

Enable gateway route propagation on the custom route table.

Disable gateway route propagation on the custom route table.

In the custom route table, add a route for

10.20.0.0/16

with the next hop type of Virtual Appliance and the next hop IP address set to

10.10.1.100

In the custom route table, add a route for

172.16.0.0/12

with the next hop type of Virtual Appliance and the next hop IP address set to

10.10.1.100

Show answer & explanation

Answer: Create a custom route table and associate it with `snet-web`.; In the custom route table, add a route for $0.0.0.0/0$ with the next hop type of Virtual Appliance and the next hop IP address set to $10.10.1.100$ .; Enable gateway route propagation on the custom route table.

Answer

To meet the requirements, you should create a custom route table, associate it with the web subnet, add a user-defined route for the default route pointing to the internal load balancer IP, and ensure that gateway route propagation is enabled on the route table.

To route internet-bound traffic through the firewalls, a custom route table must be created and associated with the web subnet containing a default route (

0.0.0.0/0

) pointing to the internal load balancer's frontend IP. By enabling gateway route propagation, the subnet automatically learns the on-premises route (

172.16.0.0/12

) via the ExpressRoute Gateway. Because of the Longest Prefix Match rule, traffic destined for the on-premises network matches the more specific propagated route and bypasses the NVAs. Meanwhile, intra-virtual-network traffic matches the system-defined local route (

10.20.0.0/16

-> Local), which is also more specific than the default route, ensuring that communication between the subnets remains local.

Step-by-Step Solution

Create a custom route table and associate it with the target subnet.

The subnet is prepared to accept user-defined routes that override default Azure system routing.

This allows applying custom routing rules specifically to the web subnet.

Add a user-defined route for the prefix

0.0.0.0/0

with the next hop type of Virtual Appliance pointing to the internal load balancer's frontend IP (

10.10.1.100

All traffic not matching a more specific route is sent to the load-balanced NVAs.

This ensures that internet-bound traffic is inspected by the firewalls in a highly available active-active configuration.

Ensure gateway route propagation is enabled on the custom route table.

The subnet automatically inherits the

172.16.0.0/12

route from the ExpressRoute Gateway.

By the Longest Prefix Match (LPM) rule, traffic destined for the on-premises network (

172.16.0.0/12

) matches the propagated route rather than the default route (

0.0.0.0/0

), routing directly to the gateway and bypassing the NVAs without administrative overhead.

Leave the local virtual network prefix route (

10.20.0.0/16

-> Local) as a system route without overriding it.

Intra-virtual-network traffic between the web and data subnets remains direct and does not transit the hub.

The system local route is more specific than the default route, ensuring local direct routing is maintained.

Key Concept

Interaction of User-Defined Routes (UDRs), system-defined routes, and BGP-propagated routes using Longest Prefix Match (LPM).

Question 67Question →

An organization is deploying a latency-sensitive public web API using Azure Functions. The API experiences unpredictable traffic spikes but must respond to all requests with minimal delay. The organization wants to use a serverless billing model that scales dynamically while completely avoiding latency spikes caused by cold starts. Which Azure Functions hosting plan should you recommend?

Premium plan

Consumption plan

Dedicated plan

Azure Kubernetes Service

Show answer & explanation

Answer: Premium plan

Answer

Premium plan

The Premium plan provides pre-warmed instances that prevent cold starts while still offering dynamic scaling and serverless billing features.

Step-by-Step Solution

Analyze the scaling and latency requirements.

The application requires dynamic auto-scaling to handle unpredictable spikes, but must avoid cold-start latency.

This rules out hosting plans that either suffer from cold starts or do not support event-driven scaling.

Evaluate the hosting options against the cold-start constraint.

The Consumption plan is eliminated due to cold starts. The Dedicated plan and Azure Kubernetes Service are eliminated because they lack native serverless scaling behavior or add significant management overhead.

To prevent latency on initial requests, pre-warmed instances are required.

Select the plan that combines serverless scaling with pre-warmed instances.

The Premium plan is chosen because it keeps instances warm to avoid cold starts while scaling out dynamically.

The Premium plan is specifically designed for serverless workloads that cannot tolerate cold starts.

Key Concept

Azure Functions hosting plans features and cold start mitigation

Estimated Time:45s

Question 68Question →

A healthtech company is designing a containerized genomic analysis system on Azure. The system has the following requirements:
- A front-end web portal and internal API microservices must scale dynamically based on HTTP traffic and queue-based events using KEDA.
- Background worker containers must process genomic sequences, taking up to 3 hours per execution. These workers must run to completion and automatically release resources when idle.
- The compute hosting solution must minimize administrative overhead and avoid managing container orchestrators.
- For compliance and data sovereignty, the application logs of the genomic background workers must be strictly segregated from the front-end portal logs, ensuring complete data isolation, separate lifecycle retention, and regional isolation.

Which three recommendations should you include in the solution?

Select all that apply

Deploy the front-end web portal and API microservices to Azure Container Apps.

Deploy the background worker containers as Azure Container Apps jobs.

Create separate Log Analytics workspaces to store the logs of the front-end portal and the background workers.

Deploy the front-end web portal and background worker containers to an Azure Kubernetes Service (AKS) cluster.

Deploy the background worker containers to Azure Functions on a Consumption plan.

Deploy a single centralized Log Analytics workspace and use Azure RBAC to restrict access to logs.

Show answer & explanation

Answer: Deploy the front-end web portal and API microservices to Azure Container Apps.; Deploy the background worker containers as Azure Container Apps jobs.; Create separate Log Analytics workspaces to store the logs of the front-end portal and the background workers.

Answer

To host the front-end portal and API microservices, deploy them to Azure Container Apps. To host the background worker containers, deploy them as Azure Container Apps jobs. For logging, create separate Log Analytics workspaces to satisfy strict compliance and data isolation requirements.

The correct recommendations involve using Azure Container Apps for the front-end and microservices to support serverless KEDA-based scaling with low administrative overhead, using Azure Container Apps jobs for the 3-hour run-to-completion background workers to avoid timeouts, and utilizing separate Log Analytics workspaces to ensure strict compliance, sovereignty, and data isolation boundaries for genomic logs.

Step-by-Step Solution

Analyze the compute requirements for the web portal and microservices.

Identify that KEDA scaling is required, and administrative overhead must be minimized.

Azure Container Apps provides serverless container hosting with native KEDA integration, satisfying these requirements without the overhead of AKS.

Analyze the compute requirements for the genomic background workers.

Identify that the tasks take up to 3 hours to process and must run to completion.

Standard Azure Container Apps are suited for continuous services, whereas Azure Container Apps jobs are designed for run-to-completion batch processing and support execution times up to 24 hours. Azure Functions on a Consumption plan is ruled out due to its 10-minute timeout limit.

Analyze the compliance and data isolation logging requirements.

Identify that strict segregation, regional sovereignty, and separate data lifecycle retention policies are required.

A single Log Analytics workspace cannot guarantee compliance boundaries at a sovereignty level; separate workspaces are required.

Synthesize the design recommendations.

Azure Container Apps for services, Azure Container Apps jobs for the background workers, and separate Log Analytics workspaces for logging.

This combination satisfies all requirements, respects the 3-hour processing constraint, enforces log segregation, and minimizes management overhead.

Key Concept

Selecting the appropriate Azure container hosting and monitoring architectures based on operational overhead, scaling behavior, execution duration, and compliance requirements.

Question 69Question →

A retail company is designing a container-based solution to process inventory updates from an Azure Service Bus queue. The application consists of a single containerized worker that must scale dynamically based on the number of messages in the queue, including scaling to zero when the queue is empty. Each message takes up to 12 minutes to process due to dependencies on legacy external systems. The company requires a solution that minimizes administrative overhead and infrastructure management. Which hosting option should you recommend for the containerized worker?

Azure Kubernetes Service (AKS)

Azure Functions on a Consumption plan

Azure Container Apps

Azure Container Instances (ACI)

Show answer & explanation

Answer: Azure Container Apps

Answer

Azure Container Apps

Azure Container Apps provides a serverless platform for hosting containerized applications and background workers with no complex infrastructure management, directly satisfying the requirement to minimize administrative overhead. It features native integration with KEDA, enabling it to scale replicas from zero up to many instances based on the Azure Service Bus queue depth. Additionally, standard container apps running in Azure Container Apps do not have the 10-minute timeout limitation that applies to Azure Functions on a Consumption plan, making it the correct service for tasks that take up to 12 minutes to process.

Step-by-Step Solution

Analyze the execution duration requirements of the queue processing container.

The message processing can take up to 12 minutes.

This rules out Azure Functions on a Consumption plan, which enforces a strict 10-minute maximum execution timeout limit.

Evaluate the infrastructure management and administrative effort constraints.

The company wants to minimize infrastructure management and administrative overhead.

This rules out Azure Kubernetes Service (AKS), as it requires managing Kubernetes control planes, node pools, routing, and updates.

Assess the remaining serverless container hosting platforms for native auto-scaling capabilities.

Azure Container Apps supports serverless hosting with native KEDA scale rules to scale to zero based on Service Bus queue length, whereas Azure Container Instances (ACI) requires custom orchestration to scale dynamically.

This identifies Azure Container Apps as the optimal solution that meets both the scaling and administrative constraints.

Key Concept

Selecting Azure container hosting platforms based on administrative effort, scaling triggers, and execution duration limits.

Question 70Question →

An enterprise is designing a hub-and-spoke network topology in Azure. The hub virtual network, `vnet-weur-hub` ( $10.10.0.0/16$ ), hosts a central network virtual appliance (NVA) at IP address $10.10.1.4$ to inspect outbound internet traffic. The spoke virtual network, `vnet-prod-spoke` ( $10.20.0.0/16$ ), contains a subnet named `snet-prod-web` ( $10.20.1.0/24$ ) that hosts web servers. You need to configure the routing so that all outbound internet traffic from `snet-prod-web` is routed through the NVA, while internal communication within the spoke virtual network remains uninterrupted. Which two configurations should you implement? (Select two.)

Select all that apply

Associate a route table with the `snet-prod-web` subnet containing a route for `

0.0.0.0/0

` with a next hop type of Virtual Appliance and IP address

10.10.1.4

Enable the 'Allow forwarded traffic' setting on the virtual network peering connection in `vnet-weur-hub` to accept traffic from the spoke.

Add a route for `

10.20.0.0/16

` to the spoke's route table with a next hop type of Virtual Appliance pointing to

10.10.1.4

Configure individual Network Security Group (NSG) rules for every external IP address on the `snet-prod-web` subnet instead of using Service Tags.

Show answer & explanation

Answer: Associate a route table with the `snet-prod-web` subnet containing a route for ` $0.0.0.0/0$ ` with a next hop type of Virtual Appliance and IP address $10.10.1.4$ .; Enable the 'Allow forwarded traffic' setting on the virtual network peering connection in `vnet-weur-hub` to accept traffic from the spoke.

Answer

To configure routing through the NVA, associate a route table with the spoke subnet containing a route for all traffic pointing to the NVA as a virtual appliance, and enable the forwarded traffic setting on the peering link to permit transit traffic.

The correct configurations involve creating a route table with a route of `

0.0.0.0/0

` pointing to the NVA's IP (

10.10.1.4

) as a Virtual Appliance and associating it with the spoke subnet, and configuring the peering connection to allow forwarded traffic. The route table directs all non-local outbound traffic to the NVA. Allowing forwarded traffic on the peering ensures that the hub VNet accepts and routes transit traffic received from the spoke.

Step-by-Step Solution

Define a route table for the spoke subnet `snet-prod-web` and add a default route of `

0.0.0.0/0

` directed to the NVA's IP address (

10.10.1.4

Outbound internet traffic from the subnet is directed to the hub's NVA.

By default, Azure routes internet-bound traffic directly to the internet. A User Defined Route (UDR) is required to override this system route.

Enable the 'Allow forwarded traffic' configuration on the peering connection between the hub and spoke.

Peering allows packets originating outside the local VNet (the spoke) to be forwarded through the hub VNet.

Without enabling forwarded traffic, Azure's virtual network peering will drop packets where the source IP address does not match the peered network space.

Key Concept

Azure Virtual Network Peering and User Defined Routes (UDR) transit configuration.

Question 71Question →

A logistics company is designing a container-based processing solution for IoT telematics data. The solution requires:
- A public-facing API that receives sensor telemetry, which must scale dynamically based on concurrent HTTP requests.
- A batch processing workload that aggregates telemetry data every evening, which takes between 15 and 45 minutes to execute.
- All workloads must run in a secure environment with no public internet access for the backend processing components.
- The design must minimize administrative and operational effort.

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

Select all that apply

An Azure Container Apps container app to host the public-facing API

An Azure Container Apps job to host the batch processing workload

An Azure Kubernetes Service (AKS) cluster to host both workloads

An Azure Functions consumption plan to host the batch processing workload

Show answer & explanation

Answer: An Azure Container Apps container app to host the public-facing API; An Azure Container Apps job to host the batch processing workload

Answer

To satisfy the requirements with the lowest operational overhead, you should recommend deploying the public-facing API as an Azure Container Apps container app and the batch processing workload as an Azure Container Apps job.

The correct recommendation is to use an Azure Container Apps container app for the public-facing API and an Azure Container Apps job for the batch processing workload. Both resources run within the same Azure Container Apps environment, allowing them to share a secure private virtual network. This satisfies the requirement to minimize administrative effort by utilizing serverless container hosting, while accommodating the 45-minute execution duration of the batch job.

Step-by-Step Solution

Evaluate the administrative overhead requirements for the containerized workloads.

Azure Kubernetes Service (AKS) is eliminated because it introduces significant operational and cluster management overhead, which fails the requirement to minimize administrative effort.

Azure Container Apps provides a serverless platform that simplifies container deployments compared to full Kubernetes cluster management.

Analyze the execution lifetime constraint of the nightly batch processor.

An Azure Functions Consumption plan is ruled out because its execution timeout limit is 10 minutes, whereas the batch processor runs for 15 to 45 minutes.

Workloads must be matched to hosting options that support their execution durations without timing out.

Identify the appropriate Azure Container Apps deployment types for the two workloads.

The public-facing API is mapped to a standard container app (which scales based on HTTP traffic), and the nightly batch process is mapped to a container apps job (which is optimized for run-to-completion batch tasks).

This configuration utilizes the appropriate built-in features of Azure Container Apps for both transactional and batch processing workloads.

Key Concept

Selecting the appropriate Azure container service and workload type based on operational overhead, scale triggers, and execution lifetime.

Estimated Time:2m 0s

Question 72Question →

A financial technology (fintech) corporation is designing a container-based credit scoring engine. The engine will run as regional microservices deployed in both the Azure North Europe and US East regions to process local credit profiles.

The design must satisfy the following requirements:
* The compute platform must automatically scale replicas based on CPU utilization and must scale down to zero replicas during off-peak hours to minimize idle costs.
* The administrative effort required to manage host operating systems, Kubernetes control planes, and orchestrator upgrades must be minimized.
* Container logs must be collected and segregated to comply with strict regional data sovereignty regulations, ensuring that European credit profile logs are never stored in or co-mingled with US-based logs.

Which solution should you recommend?

Deploy the regional microservices to internal Azure Container Apps environments in their respective regions. Configure separate Log Analytics workspaces in each region to store and isolate the container logs.

Deploy the regional microservices to Azure Kubernetes Service (AKS) clusters in each region. Configure a single centralized Log Analytics workspace in the primary region to consolidate all container logs.

Deploy the regional microservices to internal Azure Container Apps environments in their respective regions. Configure a single centralized Log Analytics workspace in the primary region with Table-level Role-Based Access Control (RBAC) to restrict access.

Deploy the regional microservices to Azure Container Instances (ACI) mapped to private virtual networks in each region. Configure separate Log Analytics workspaces in each region to store and isolate the container logs.

Show answer & explanation

Answer: Deploy the regional microservices to internal Azure Container Apps environments in their respective regions. Configure separate Log Analytics workspaces in each region to store and isolate the container logs.

Answer

Deploy the regional microservices to internal Azure Container Apps environments in their respective regions and configure separate Log Analytics workspaces in each region to store and isolate the container logs.

Deploying the microservices to internal Azure Container Apps (ACA) environments in their respective regions combined with separate regional Log Analytics workspaces meets all design constraints. ACA is a serverless hosting platform that minimizes administrative overhead by eliminating Kubernetes control plane and VM host management, and natively supports scaling to zero based on CPU utilization. Regional Log Analytics workspaces ensure that European logs are kept completely separate from US logs, satisfying data sovereignty requirements.

Step-by-Step Solution

Evaluate the compute hosting requirements.

Identify that the solution requires microservices hosting with automatic scaling based on CPU utilization, scale-to-zero capability, and minimal administrative overhead (no VM host or control plane patching).

This rules out Azure Kubernetes Service (AKS) due to high management overhead, and rules out Azure Container Instances (ACI) since it lacks native metric-based scaling to zero.

Evaluate the regulatory and compliance logging requirements.

Identify that data sovereignty regulations prohibit co-mingling or storing European logs in the US region (or vice versa).

This mandates the use of separate Log Analytics workspaces in each region rather than a centralized single workspace, regardless of access control mechanisms like RBAC.

Synthesize the compute and logging components to select the best option.

Select the combination of regional internal Azure Container Apps environments and separate regional Log Analytics workspaces.

This combination satisfies both the serverless compute scaling requirements and the strict regional log segregation compliance requirements.

Key Concept

Selecting container hosting platforms and designing regional monitoring boundaries for compliance and operational efficiency.

Question 73Question →

You need to configure a Network Security Group (NSG) to allow outbound traffic from an Azure virtual network subnet to Azure SQL Database instances. The solution must block all other traffic to the internet, minimize administrative effort, and avoid manual IP address management when Azure services update their IP address ranges. Which destination setting should you specify in the outbound security rule of the Network Security Group?

The Sql Service Tag

A list of individual public IP address ranges for the Azure SQL Database service

An Application Security Group containing the Azure SQL Database service

A User-Defined Route that overrides default system routes to direct traffic through a custom gateway

Show answer & explanation

Answer: The Sql Service Tag

Answer

The Sql Service Tag

The correct solution is to use the 'Sql' Service Tag as the destination. A Service Tag represents a group of IP address prefixes from a given Azure service. Using service tags eliminates the need to manually update security rules when IP addresses change, minimizing administrative effort.

Step-by-Step Solution

Identify the target service requiring outbound connectivity and the administrative constraint.

The target is Azure SQL Database, and the solution must avoid manual IP updates.

This establishes that we need a dynamic referencing mechanism rather than static IP configurations.

Select the appropriate Network Security Group destination option that groups the target service's IP addresses.

The built-in 'Sql' Service Tag is selected.

Service tags abstract IP prefixes for specific Azure services and are managed automatically by Microsoft, fulfilling all constraints.

Key Concept

Using Service Tags in Network Security Groups to simplify security rules and eliminate manual IP address maintenance for Azure services.

Estimated Time:45s

Question 74Question →

An enterprise is designing a secure hub-and-spoke network topology in Azure. The topology consists of the following components:

* A hub virtual network named `vnet-prod-hub` ( $10.100.0.0/16$ ) containing:
* A subnet named `snet-nva` ( $10.100.1.0/24$ ) that hosts a Network Virtual Appliance (NVA) at IP address $10.100.1.4$ .
* A subnet named `GatewaySubnet` ( $10.100.2.0/24$ ) that hosts an ExpressRoute Virtual Network Gateway.
* A peered spoke virtual network named `vnet-prod-spoke` ( $10.200.0.0/16$ ) containing a subnet named `snet-app` ( $10.200.1.0/24$ ).

The ExpressRoute gateway connects to an on-premises network ( $192.168.0.0/16$ ). Virtual network peering is configured to allow gateway transit.

You need to design a routing solution that meets the following requirements:
1. All traffic from `snet-app` destined for the on-premises network must be inspected by the NVA.
2. All traffic from the on-premises network destined for `snet-app` must be inspected by the NVA.
3. The NVA must be able to forward inspected traffic to its final destination without routing loops or losing connectivity.

Which two configurations should you include in the design?

Select all that apply

Associate a route table with the GatewaySubnet that contains a route for 10.200.0.0/16 with the next hop set to Virtual appliance (10.100.1.4).

Associate a route table with snet-app that contains a route for 192.168.0.0/16 with the next hop set to Virtual appliance (10.100.1.4), and disable BGP route propagation on the route table.

Associate a route table with snet-nva that contains a route for 10.100.0.0/16 with the next hop set to Virtual appliance (10.100.1.4).

Disable BGP route propagation on the route table associated with the GatewaySubnet.

Associate a route table with snet-app that contains a route for 10.100.0.0/16 with the next hop set to Virtual Network Gateway.

Show answer & explanation

Answer: Associate a route table with the GatewaySubnet that contains a route for 10.200.0.0/16 with the next hop set to Virtual appliance (10.100.1.4).; Associate a route table with snet-app that contains a route for 192.168.0.0/16 with the next hop set to Virtual appliance (10.100.1.4), and disable BGP route propagation on the route table.

Answer

The correct configurations are to: 1) Associate a route table with the GatewaySubnet that contains a route for the spoke network space pointing to the NVA as a virtual appliance, and 2) Associate a route table with the spoke subnet containing a route for the on-premises network space pointing to the NVA as a virtual appliance, while disabling BGP route propagation on that route table.

To inspect traffic in both directions, custom routing must be applied to both the spoke subnet and the gateway subnet. Outbound traffic is redirected by associating a route table to the spoke subnet with a UDR for the on-premises network range pointing to the NVA. BGP route propagation must be disabled on the spoke subnet's route table to prevent dynamically advertised routes from on-premises from bypassing the UDR. Inbound traffic is redirected by associating a route table with the GatewaySubnet that contains a UDR for the spoke network range pointing to the NVA, overriding the default system peering route.

Step-by-Step Solution

Configure outbound routing from the spoke to the NVA.

Associate a route table with the spoke subnet (`snet-app`) containing a UDR for `192.168.0.0/16` pointing to the NVA (`10.100.1.4`) as the next hop.

This ensures that traffic originating from the application tier destined for on-premises is sent to the NVA for inspection instead of using the default system-propagated route.

Ensure BGP routes do not override the outbound UDR.

Disable BGP route propagation on the route table associated with `snet-app`.

By default, Azure system routes learned via BGP (such as specific subnets advertised by the on-premises edge router) take precedence over broader UDRs if they represent a more specific prefix. Disabling route propagation prevents the subnet from dynamically learning these routes, forcing all traffic to follow the custom UDR.

Configure inbound routing from the gateway to the NVA.

Associate a route table with `GatewaySubnet` containing a UDR for `10.200.0.0/16` pointing to the NVA (`10.100.1.4`) as the next hop.

When traffic returns from the on-premises network, the gateway would normally route it directly to the spoke via the default VNet Peering system route. A UDR on the `GatewaySubnet` overrides the default peering path and forces the gateway to send the traffic to the NVA first.

Key Concept

Azure Custom Routing, Gateway Subnet UDRs, and BGP Route Propagation Controls

Estimated Time:2m 30s

Question 75Question →

A digital media publishing company is designing a new platform on Azure to manage content delivery and media transformation. The platform has the following components:

* A set of front-end and back-end API microservices that experience highly variable HTTP traffic and must scale to zero instances during idle periods to minimize costs.
* A video-rendering service that requires deploying custom Kubernetes Custom Resource Definitions (CRDs) and custom operators to orchestrate rendering tasks.
* A background analytics worker that must process message queues and requires Event-Driven Autoscaling (KEDA) integration.

The design must minimize administrative overhead where possible.

Which two container hosting solutions should you recommend? (Select two.)

Select all that apply

Azure Container Apps for the API microservices and the background analytics worker

Azure Kubernetes Service (AKS) for the video-rendering service

Azure Kubernetes Service (AKS) for the API microservices and the background analytics worker

Azure Container Apps for all three components, including the video-rendering service

Azure Container Instances (ACI) for the video-rendering service

Show answer & explanation

Answer: Azure Container Apps for the API microservices and the background analytics worker; Azure Kubernetes Service (AKS) for the video-rendering service

Answer

Azure Container Apps for the API microservices and the background analytics worker, and Azure Kubernetes Service (AKS) for the video-rendering service.

The correct solution uses Azure Container Apps for the API microservices and background worker, and Azure Kubernetes Service (AKS) for the video-rendering service. Azure Container Apps is designed to minimize administrative overhead by abstracting Kubernetes management, and it natively supports scaling to zero and event-driven scaling (KEDA). However, because Azure Container Apps does not expose the Kubernetes API or support the deployment of custom Kubernetes Custom Resource Definitions (CRDs) and custom operators, the video-rendering service must be hosted on Azure Kubernetes Service (AKS), which provides full access to the Kubernetes control plane.

Step-by-Step Solution

Evaluate the requirements of the API microservices and background analytics worker.

These components require rapid scaling, scale-to-zero capabilities, and KEDA integration, and the organization wishes to minimize administrative overhead.

Azure Container Apps is a fully managed serverless platform that natively supports scaling to zero and event-driven scaling (KEDA) without the operational overhead of managing a Kubernetes cluster.

Evaluate the requirements of the video-rendering service.

The video-rendering service requires deploying custom Kubernetes Custom Resource Definitions (CRDs) and custom operators.

Deploying custom CRDs and operators requires direct access to the Kubernetes API. Since Azure Container Apps completely abstracts the Kubernetes control plane, Azure Kubernetes Service (AKS) must be used to provide direct API access.

Select the correct combination of container hosting options.

Recommend Azure Container Apps for the API microservices and analytics worker, and Azure Kubernetes Service (AKS) for the video-rendering service.

This design satisfies all requirements while minimizing administrative overhead where possible by utilizing serverless containers where appropriate.

Key Concept

Determining when to use Azure Container Apps versus Azure Kubernetes Service (AKS) based on operational overhead, scale-to-zero requirements, and the need for direct Kubernetes API access (CRDs/operators).

Question 76Question →

An architect is designing a virtual network topology in Azure to support a hybrid cloud environment. The design includes a hub virtual network named `vnet-prod-hub` and a spoke virtual network named `vnet-prod-spoke`. The hub virtual network contains a virtual network gateway that connects to the company's on-premises office. A virtual network peering connection is established between `vnet-prod-hub` and `vnet-prod-spoke`. You need to ensure that virtual machines in `vnet-prod-spoke` can route their traffic to the on-premises office by using the virtual network gateway in `vnet-prod-hub`. What peering setting should you enable on the virtual network peering configuration in `vnet-prod-spoke`?

Enable 'Use the remote virtual network's gateway' on the peering configuration from the spoke to the hub.

Enable 'Use this virtual network's gateway' on the peering configuration from the spoke to the hub.

Create a User Defined Route (UDR) in the spoke subnets that overrides the default local virtual network routing paths.

Configure individual Network Security Group (NSG) outbound rules for each on-premises destination IP range.

Show answer & explanation

Answer: Enable 'Use the remote virtual network's gateway' on the peering configuration from the spoke to the hub.

Answer

Enable 'Use the remote virtual network's gateway' on the peering configuration from the spoke to the hub.

To allow resources in a spoke virtual network to use a gateway in a peered hub virtual network, you must enable the 'Use the remote virtual network's gateway' setting on the spoke virtual network's peering configuration. This configures the system routes in the spoke to route traffic destined for on-premises networks through the hub gateway.

Step-by-Step Solution

Identify the location of the virtual network gateway.

The gateway is in the hub virtual network (vnet-prod-hub).

This determines which virtual network acts as the transit network for hybrid connectivity.

Configure gateway transit on the hub virtual network's peering.

The hub peering configuration must allow gateway transit (Use this virtual network's gateway).

This allows the hub virtual network to share its gateway with peered spoke networks.

Configure the spoke virtual network's peering settings.

Enable 'Use the remote virtual network's gateway' on the peering configuration from vnet-prod-spoke to vnet-prod-hub.

This allows the virtual machines in the spoke virtual network to route transit traffic through the gateway in the peered hub virtual network.

Key Concept

Virtual network peering gateway transit allows peered virtual networks to share a gateway for hybrid connectivity, removing the need to deploy gateways in every spoke.

Estimated Time:1m 0s

Question 77Question →

Your company has virtual machines deployed in an Azure Virtual Network subnet. The virtual machines must be allowed to retrieve secrets from Azure Key Vault and access files stored in Azure storage accounts. You need to configure a Network Security Group (NSG) to permit this outbound traffic. The design must minimize administrative overhead and avoid the configuration of individual IP addresses. Which two service tags should you include in the outbound security rules of the NSG?

Select all that apply

AzureKeyVault

Storage

AzureStorage

A list of individual public IP addresses for the Azure Key Vault and Azure Storage endpoints

Show answer & explanation

Answer: AzureKeyVault; Storage

Answer

The correct service tags are AzureKeyVault and Storage.

The service tags AzureKeyVault and Storage are the official, built-in tags provided by Microsoft to represent all IP address prefixes for Azure Key Vault and Azure Storage, respectively. Implementing these tags in the NSG rules allows outbound access to these services without requiring manual configuration or maintenance of individual IP ranges.

Step-by-Step Solution

Identify the target Azure services requiring outbound network access from the subnet.

The services are Azure Key Vault and Azure Storage.

Outbound security rules must allow access to these specific services.

Evaluate the requirement to minimize administrative overhead and avoid individual IP addresses.

Determine that built-in Azure service tags must be used instead of manually maintaining IP lists.

Service tags automatically manage the IP address prefixes for Azure services, reducing administrative work.

Identify the exact names of the service tags for Azure Key Vault and Azure Storage.

The service tag for Azure Key Vault is AzureKeyVault, and the service tag for Azure Storage is Storage.

Using the exact service tag names ensures the NSG rules are valid and function correctly.

Key Concept

Azure Virtual Network service tags simplify network security group (NSG) configuration by representing a group of IP address prefixes from a specific Azure service.

Question 78Question →

An architect is evaluating Azure compute options for a web API. The solution must satisfy the following requirements:

- Process incoming HTTP requests that trigger complex calculations lasting up to $15$ minutes.
- Establish secure outbound communication to a backend database via a Private Endpoint inside an Azure Virtual Network (VNet).
- Automatically scale down to zero instances during idle periods to eliminate compute charges.
- Minimize administrative and infrastructure management overhead.

Which hosting option should the architect recommend?

Azure Functions on a Consumption plan

Azure Functions on an Elastic Premium plan

Azure Functions on a Flex Consumption plan

Azure Container Apps

Show answer & explanation

Answer: Azure Functions on a Flex Consumption plan

Answer

Azure Functions on a Flex Consumption plan

The hosting option specifying Azure Functions on a Flex Consumption plan is correct. This hosting plan natively supports outbound Virtual Network integration, allowing secure communication to the database private endpoint. It scales to zero instances during inactivity, resulting in zero compute charges, and supports HTTP execution timeouts of up to

330

minutes, satisfying the

15

-minute requirement.

Step-by-Step Solution

Evaluate the execution duration requirement against the candidate hosting options.

The Consumption plan is eliminated due to its

10

-minute execution timeout. Azure Container Apps is eliminated because its HTTP ingress enforces a hard

120

-second timeout limit for direct HTTP requests.

Architectural constraints require support for

15

-minute request durations, which exceeds the limit of these plans.

Evaluate network security and cost requirements.

The Elastic Premium plan is eliminated because it requires at least one pre-warmed instance, violating the requirement of scaling down to zero compute charges during idle periods.

The solution must support outbound Virtual Network integration to connect to a private endpoint and scale to zero compute charges.

Verify Flex Consumption plan capabilities against all requirements.

Flex Consumption supports outbound Virtual Network integration via subnet delegation, scales to zero instances (incurring zero cost when idle), and has a maximum execution timeout of

330

minutes (exceeding the

15

-minute requirement).

Flex Consumption combines the network integration of premium hosting plans with the scale-to-zero billing of consumption hosting plans.

Key Concept

Selecting the appropriate Azure compute and hosting plan based on execution limits, virtual network integration, and scale-to-zero cost requirements.

Question 79Question →

A media streaming company is designing a container-based processing solution for transcribing audio files. The transcoder containers run as background tasks that can take up to 45 minutes to process large files. The solution must scale dynamically based on the number of audio files uploaded to Azure Blob Storage, scale to zero when no files are present, and minimize operational overhead. Which solution should you recommend?

Azure Container Apps jobs

Azure Functions running containerized workloads on a Consumption plan

Azure Kubernetes Service (AKS) hosting a custom worker deployment

Azure Container Instances (ACI) grouped under a single central Log Analytics workspace for all compliance jurisdictions

Show answer & explanation

Answer: Azure Container Apps jobs

Answer

Azure Container Apps jobs

Azure Container Apps jobs are designed specifically for processing run-to-completion tasks. They natively support event-driven scaling (e.g., using KEDA scaling rules based on queue or storage metrics), allow executions to run beyond 10 minutes (up to 24 hours), and minimize administrative effort by running on a serverless platform where Azure manages the underlying infrastructure.

Step-by-Step Solution

Analyze the execution duration requirement of the workload.

The transcribing task can take up to 45 minutes, ruling out standard serverless options with a 10-minute limit.

Ensures the selected hosting environment supports long-running execution without timeout failures.

Evaluate operational overhead and scaling requirements.

The solution requires scaling to zero based on event triggers (Blob Storage uploads) and minimum operational overhead.

Rules out complex container orchestrators like Azure Kubernetes Service (AKS) which require cluster management.

Compare Azure Container Apps jobs against other Azure container solutions.

Azure Container Apps jobs support run-to-completion tasks, scale to zero, handle executions over 10 minutes, and run on a serverless platform.

Confirms the optimal service recommendation aligned with Microsoft Best Practices.

Key Concept

Selecting the appropriate Azure container hosting option based on workload duration, scaling requirements, and operational overhead.

Question 80Question →

An organization needs to design a secure administration path for its development workloads. Developers must be able to establish Remote Desktop Protocol (RDP) connections to virtual machines over the internet. The solution must restrict public internet exposure by ensuring the virtual machines do not have public IP addresses, and it must avoid the management overhead of client-based virtual private network (VPN) software. Which service should you recommend to meet these requirements?

Azure Bastion

Azure Application Gateway

A Network Security Group with rules allowing inbound RDP traffic from explicit public IP addresses

Azure ExpressRoute

Show answer & explanation

Answer: Azure Bastion

Answer

Azure Bastion

Azure Bastion is a fully platform-managed PaaS service that provides secure and seamless RDP and SSH access to virtual machines directly through the Azure portal. Since it operates as a gateway inside the virtual network, VMs do not require public IP addresses, and administrators do not need to install client-side VPN software.

Step-by-Step Solution

Analyze the access requirement

Administrators need to connect to Azure VMs using RDP over the internet.

This establishes the protocol and target environment for the administration connection.

Evaluate the connectivity and agent constraints

The VMs must not have public IP addresses, and no VPN client software should be installed on client machines.

This rules out direct RDP exposure (which requires public IPs or NAT) and traditional Point-to-Site VPNs (which require VPN client software).

Select the appropriate Azure service

Azure Bastion satisfies these conditions by provisioning a managed gateway that brokers RDP/SSH traffic over HTTPS (SSL) directly in the browser.

Azure Bastion allows secure connectivity without public IPs on virtual machines and without client-side VPN components.

Key Concept

Azure Bastion provides secure, clientless RDP/SSH access to virtual machines within a virtual network without exposing public IPs.

PreviousPage 4 / 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

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

Key Concept