Design infrastructure solutions practice questions

Use a single virtual network for all resources with a network virtual appliance.

Why it fails: Azure virtual networks are scoped to a single subscription, so a single VNet cannot span or be directly shared across multiple Azure subscriptions; each subscription would need its own VNet with peering or a gateway. Even if you forced resources into one VNet, it would quickly exhaust per-VNet limits such as the 65,536 total resources and 50,000 peerings, making the architecture unscalable. A single network virtual appliance (NVA) placed in that VNet would also become a performance bottleneck and single point of failure, especially when all outbound traffic from every subscription and on-premises site must traverse it. This design mixes unrelated workloads and fails to provide the isolation and independent management that the hub-spoke model offers.

Use an Azure Virtual WAN with security virtual WAN hub.

Why it fails: Using an Azure Virtual WAN with a security virtual WAN hub provides centralised internet egress for connected Azure VNets and integrates ExpressRoute. However, it is primarily designed for large-scale, global network connectivity and simplifying branch office integration, not specifically for enforcing a single web filtering policy for existing ExpressRoute connections to on-premises data centres. This solution would be appropriate for consolidating a complex global network with numerous branch sites requiring simplified, managed connectivity and security services.

Use Azure Traffic Manager with Azure Firewall.

Why it fails: Azure Traffic Manager is a DNS-based load balancer for distributing traffic across endpoints. It cannot enforce outbound traffic policies. Azure Firewall is a security service, but without proper routing (UDRs) and VNet architecture, it cannot control outbound traffic from multiple VNets.

A

Why it fails: Azure Kubernetes Service (AKS) is a managed Kubernetes cluster, but 'managed' only means the control plane is maintained by Azure; you still must handle node pool sizing, OS patching, upgrading Kubernetes versions, autoscaler tuning, and monitoring for the nodes. For a simple microservices app that doesn't need complex service discovery, ingress controllers, or stateful orchestration, this operational overhead outweighs the benefits, and you are billed for the underlying VMs even when no containers are running.

C

Why it fails: Azure App Service for Containers is built for hosting web applications, with a built-in HTTP load balancer, auto-scaling per-app, and continuous deployment support. However, each App Service plan is allocated fixed VM sizes and billing tiers, and the platform is optimized for long-running web endpoints rather than short-lived, generic container workloads; per-second billing is not available, and scaling requires either adjusting the plan tier or configuring autoscale rules, which adds latency and cost compared to ACI's instantaneous, per-second model.

D

Why it fails: Azure Virtual Machines with Docker require you to provision and manage the VM lifecycle: apply OS security patches, configure Docker daemon, manage container restarts, handle disk encryption, and set up a load balancer for scaling. You are paying for the VM even when containers are idle, and scaling requires manually creating or deallocating VMs or configuring VMSS, which involves significant operational staff time and complexity. For a simple microservices application, this is the antithesis of minimizing operational overhead and is generally reserved for legacy workloads that cannot use serverless or PaaS options.

Azure API Management

Why it fails: Azure API Management (APIM) is a dedicated API gateway designed to publish, secure, and monitor APIs for internal and external consumers. When deployed in internal VNet mode, its gateway endpoint is private by default, but it can be exposed to external partners through a public IP or via an external front-end device while retaining all of its own API security features. APIM natively integrates with OAuth2, supports subscription-based rate limiting and quotas, caching, CORS, and rich policy definitions, making it the correct service for securely exposing APIs to external partners.

Azure Front Door

Why it fails: Front Door is a global, cloud-scale entry point that offers HTTP/HTTPS load balancing across backends, SSL offload, path-based routing, and content caching through a large edge network, along with a global WAF. It is a CDN and application delivery controller, not an API gateway; it lacks the ability to manage API subscriptions, issue or validate OAuth2 tokens, enforce per-subscription throttling, or apply API transformation and governance policies. Although it may accelerate and protect HTTP traffic, it does not provide the API-level management capabilities required in this scenario.

Azure Traffic Manager

Why it fails: Traffic Manager provides DNS-based traffic routing to distribute traffic across global Azure endpoints based on routing methods like performance, failover, or geographic priority. It works at the DNS resolution level and has no awareness of HTTP/HTTPS content, so it cannot perform TLS termination, URL-path inspection, or apply any kind of API policy. It simply resolves a domain name to the appropriate endpoint IP and is therefore completely unsuitable for exposing an API with authentication, rate limiting, and monitoring.

Point-to-Site VPN gateway

Why it fails: A Point-to-Site (P2S) VPN gateway is a network gateway that terminates client-to-VNet VPN tunnels using protocols like OpenVPN, IKEv2, or SSTP. While it can reach a private VM, it requires a public IP on the gateway, opens an inbound path from the internet into the VNet, and forces you to install a VPN client; it also does not natively use Microsoft Entra ID to authorize the actual RDP/SSH session, because VPN authentication and VM login are separate steps. Finally, if the VM has no public IP, you would still need a separate RDP/SSH client on the VPN-connected device, so this is not a streamlined portal-based access solution.

Azure ExpressRoute

Why it fails: Azure ExpressRoute creates a dedicated, private Layer 3 connection between an on-premises network and Azure, bypassing the public internet. However, it is a network-connectivity service, not a remote-administration gateway: it does not provide any RDP/SSH proxy or portal-based session, and it does not expose individual VMs for browser access. To use it for admin access, an administrator must already be on a network that is routed through the ExpressRoute circuit and would still need a jump box, since your VMs are private and ExpressRoute itself does not terminate any remote-desktop protocol.

Microsoft Entra ID Application Proxy

Why it fails: Microsoft Entra ID Application Proxy is designed to publish HTTP/HTTPS web applications for remote users through an external URL, using a connector that pulls requests and does not open any inbound ports. It is not a TCP/UDP proxy and cannot carry RDP/SSH traffic, so it cannot provide remote desktop or SSH sessions to Azure VMs. Even if you have an internal RDP/SSH tool with a web-based front end, Application Proxy only supports web-based (HTTP/S) endpoints, not the port-443-reserved, protocol-aware tunnel that Azure Bastion provides.

VNet peering with user-defined routes (UDRs) and network virtual appliances (NVAs)

Why it fails: VNet peering with user-defined routes and NVAs can technically create a hub-and-spoke design, but it requires you to manually attach UDRs to every spoke subnet so traffic to other spokes is forced through the NVA. Nothing in the peering relationship itself blocks direct spoke-to-spoke connectivity; if a UDR is missing or misconfigured, spokes communicate directly. The solution also demands ongoing management of NVA scaling, availability, and route updates, making it operationally heavy and error-prone compared with a centralized routing service.

Azure VPN Gateway with route-based VPN

Why it fails: A route-based Azure VPN Gateway is designed to connect on-premises networks to Azure via IPsec tunnels; it does not provide a managed hub-and-spoke topology among multiple VNets. Even if you attached VPN gateways to each VNet, you would be building a complex mesh or hub with additional gateways and custom routing, not a centralized routing policy that blocks inter-spoke traffic. It also lacks built-in traffic inspection and routing policies, so it fails the requirement for centralized control with minimal overhead.

Azure ExpressRoute with private peering

Why it fails: Azure ExpressRoute with private peering offers dedicated, private connectivity from your on-premises infrastructure to Azure, but it has no role in routing traffic between VNets within Azure. ExpressRoute circuits connect to a single Microsoft Enterprise Edge (MSEE) and can reach VNets through connection gateways, but they do not aggregate or filter VNet-to-VNet traffic, nor do they provide any hub-and-spoke routing controls. Therefore, it cannot address the requirement for centralized inspection and prevention of direct spoke-to-spoke communication.

Azure Front Door with WAF and DDoS Protection

Why it fails: Azure Front Door is unsuitable here because it is a global, multi-region routing service, not designed for load balancing traffic *within* a single Azure region to VMs in an availability set. For intra-regional distribution to VMs, a regional load balancer is required. However, it is tempting as it provides the requested SSL termination, health probes, WAF, and DDoS protection. Front Door would be the correct choice for globally distributed web applications needing multi-region failover, content delivery optimisation, or routing to diverse public endpoints across different geographical locations.

Azure Traffic Manager and Azure Load Balancer

Why it fails: Azure Traffic Manager operates at the DNS level and merely routes clients to an endpoint based on routing method; it never inspects or terminates HTTP/S traffic. Azure Load Balancer is a layer-4 service that distributes TCP/UDP flows and lacks application-layer features such as SSL termination, HTTP health probes, and any Web Application Firewall capability. Together they provide no WAF protection and no SSL offload, so they fail to meet the stated requirements.

Azure CDN with WAF

Why it fails: Azure CDN with WAF caches static content at edge PoPs and filters requests at delivery nodes, but it is not a load balancer for dynamic application traffic and does not monitor the health of backend VMs in an availability set. A CDN is designed to accelerate content delivery, not to route requests to the appropriate VM based on backend availability or load. Applying WAF at the CDN edge leaves the origin application exposed to direct attacks, and the architecture still needs a regional load balancer to distribute incoming connections.

Azure Load Balancer

Why it fails: Azure Load Balancer is a layer 4 (TCP/UDP) service, so it simply forwards IP flows to backend VMs without inspecting HTTP headers, URLs, or cookies. Its health probes only check reachability of a port or a basic HTTP 200 response, and it cannot perform SSL termination or application-aware routing. For a web application requiring HTTP-level features such as path-based routing or sticky sessions, this lack of L7 functionality makes it insufficient.

Azure Traffic Manager

Why it fails: Azure Traffic Manager operates at the DNS level, resolving a domain name to the IP address of one of its configured endpoints rather than forwarding individual network connections. It steers entire user sessions to a single endpoint (usually a regional deployment), but cannot distribute HTTP requests among VMs within a region or inspect traffic at the application layer. Since the VMs are in a single region and need request-level load balancing, Traffic Manager's DNS-based routing is not a viable substitute.

Azure Front Door

Why it fails: Azure Front Door is a global HTTP(S) traffic router that uses anycast to direct requests to the nearest regional endpoint, offering CDN caching, SSL offload, and a WAF at the internet edge. Although it could technically reach the VMs, it is built for multi-region deployments and global acceleration, not for simply balancing traffic among availability zones within one region. Deploying Front Door when all VMs reside in the same region would introduce unnecessary cost and operational complexity without providing meaningful benefit.

Federation with AD FS

Why it fails: Federation with AD FS routes authentication to on-premises Active Directory and never sends password hashes to Microsoft Entra ID. Password changes are therefore not replicated into the cloud identity store, and cloud resources depend on an AD FS farm and on-premises DC availability for every sign-in. This separation of authentication from credential storage does not meet the requirement for near real-time password hash propagation to Microsoft Entra ID.

Pass-through Authentication

Why it fails: Pass-through Authentication validates each sign-in against on-premises Active Directory but does not sync user password hashes to Microsoft Entra ID. Consequently, password modifications are not mirrored in the cloud, and the system has no local copy of the credential to power checks like leaked credential detection. It requires on-premises agents for every authentication attempt, so it fails the stated need for the password hash to be synchronized to the cloud.

Microsoft Entra Cloud Sync

Why it fails: Microsoft Entra Cloud Sync provides lightweight object synchronization for small environments but is not a full replacement for Microsoft Entra Connect when password hash synchronization is required. In the context of this question, Cloud Sync alone does not implement the password change replication described in the requirement; enabling Password Hash Sync still requires Microsoft Entra Connect with the dedicated PHS feature. Therefore, choosing Cloud Sync would leave the company without the near real-time password hash update this design needs.

The VM will be created but a compliance alert will be generated.

Why it fails: Azure Policy's 'deny' effect, unlike 'audit', actively blocks resource creation during deployment, so the request fails rather than proceeding with a compliance alert. An 'audit' effect would allow the VM to be created and then flag it as non-compliant, but because this policy is configured with 'deny', the creation attempt is preemptively rejected and no VM or alert is ever generated.

The VM will be created but the size will be changed to Standard_D2s_v3.

Why it fails: Azure Policy is not a resource reconfiguration service; it evaluates the deployment request against the policy rules before any resource is provisioned and rejects the request if it is non-compliant. The 'deny' effect does not trigger a remediation that changes the VM size to Standard_D2s_v3—automatic correction would require a separate 'deployIfNotExists' or 'modify' effect and a remediation task, and even then the original request itself is still blocked.

The VM will be created successfully.

Why it fails: The requested VM size falls outside the allowed list, and the policy engine evaluates the deployment synchronously, returning a denial that prevents the creation from succeeding. A successful creation would only be possible if the chosen size were included in the allowed list, which directly contradicts the given scenario, making this outcome impossible under the stated policy.

The number of failed VM creation attempts per hour.

Why it fails: The query filters for 'Succeeded' activities, not failed.

The total number of successful operations across all Azure resources.

Why it fails: The query filters for VM write operations only.

A list of all Azure activity log entries.

Why it fails: The query aggregates and summarizes, not lists all entries.

Azure Site Recovery for SQL Server

Why it fails: Azure Site Recovery replicates entire virtual machines at the hypervisor level using asynchronous replication, but it does not natively understand SQL Server transaction log semantics. While it can take application-consistent snapshots for SQL Server, replication is at the VM level, not the database level, so the recovery point objective (RPO) is typically measured in minutes, not seconds, and cannot meet a 5-second RPO requirement.

Failover groups with auto-failover

Why it fails: Failover groups with auto-failover are built on active geo-replication, but they prioritize automated failover and high availability over minimal data loss, with an RPO that can be up to 1 hour under certain conditions. This means a regional disaster could lose up to an hour of transactions, which violates the 5-second RPO requirement, so they are not suitable for this scenario despite their convenience.

Geo-restore of SQL Database backups

Why it fails: Geo-restore of SQL Database backups restores a database from a geo-redundant backup stored in paired Azure regions, but the last backup is typically taken up to an hour before the failure, giving it an RPO of at least 1 hour. Additionally, the restore process can take several hours (RTO), making this option entirely inadequate for a disaster recovery solution that requires an RPO of only 5 seconds.

Spot node pools

Why it fails: Spot node pools run on surplus Azure capacity and can be evicted at any time when Azure needs the capacity back, so they are unsuitable for a production single-tenant workload that must be always available. Moreover, spot nodes do not receive the same automatic security patching as system node pools; you must manually handle node image upgrades and also account for eviction-triggered pod rescheduling. This option fails the core requirement for managed security updates because the platform does not guarantee a stable, automatically patched infrastructure.

User node pools

Why it fails: User node pools in AKS are designed to host your application pods, and they are distinct from system node pools that host critical system pods such as CoreDNS and metrics-server. While you can apply auto-upgrade channels to user pools, the platform does not treat them as the default managed patching layer—you are responsible for selecting and maintaining upgrade/deployment behavior. They also share the same AKS cluster control plane, so they do not provide a uniquely dedicated, automatically patched worker node environment for a single-tenant application; instead, system node pools are the intended mechanism for that.

Virtual nodes (serverless)

Why it fails: Virtual nodes use the serverless Azure Container Instances (ACI) layer, meaning pods run on infrastructure that is fully abstracted and not exposed as worker nodes in your AKS node pool. Because there is no worker node in your cluster, the AKS automatic patching model for node images does not apply to virtual nodes—you have no control over or visibility into the underlying node security updates. Additionally, virtual nodes are primarily designed for burst scaling or scheduling pods without managing nodes, not for providing a dedicated, automatically patched worker infrastructure for a critical single-tenant application.

Use Azure Application Gateway with WAF

Why it fails: Application Gateway is for L7, not for encrypting VM-to-VM traffic.

Use Azure Front Door

Why it fails: Azure Front Door is for global web delivery.

Use VNet peering to connect the tiers

Why it fails: VNet peering does not provide encryption.

Dynamic private IP address

Why it fails: A dynamic private IP address is assigned from the subnet when the VM is created and remains for the VM's lifetime while it is running; however, if the VM is deallocated (Stop-Deallocate), the IP can be released and a different address from the subnet may be assigned upon the next start. For a legacy application, this makes the address unreliable for DNS records, connection strings, or security rules that depend on the internal IP, so it doesn't meet the requirement of a stable endpoint during migration.

Dynamic public IP address

Why it fails: A dynamic public IP address is allocated when the VM starts, but once the VM is deallocated or stopped, the IP is released back to the pool and a new, different public IP is assigned on the next start. Because the public endpoint changes after downtime, clients using allow-listed IPs or DNS names would fail to reconnect. In contrast, a static public IP remains fixed for the lifetime of the resource, making it the better choice for a persistent destination.

Ephemeral IP address

Why it fails: An ephemeral IP address is a short-lived, transient address designed for temporary outbound connectivity, not for exposing a VM as a permanent service endpoint. It is not retained when the VM stops or restarts, and it does not provide a stable identity that clients or administrators can rely on for the migration. Because the scenario requires a lasting public or private address, an ephemeral IP is unsuitable.

Azure Key Vault (Standard) with Azure Storage encryption

Why it fails: This configuration encrypts Azure Storage with a customer-managed key, but Azure Key Vault (Standard) stores keys in software, not in an HSM. For a financial services workload handling sensitive customer data, regulatory standards typically require FIPS 140-2 Level 3 validated hardware protection. The Standard tier therefore fails the HSM-backed key requirement, even though storage encryption itself is enabled.

Azure Key Vault (Premium) with custom rotation logic

Why it fails: Azure Key Vault (Premium) does provide HSM-protected keys, so the security boundary is satisfied. However, key rotation is not built-in; you must write and maintain custom automation to generate new key versions, update aliases, and handle any failure scenarios. That custom rotation logic is error-prone and does not meet the requirement for an automatic rotation policy, especially compared to a fully managed service.

Azure Storage encryption with customer-managed keys stored in Azure Key Vault (Standard)

Why it fails: While Azure Storage encryption is always enabled at the platform level, using a customer-managed key does not change that; the real differentiator is the key vault tier. Storing that key in Azure Key Vault (Standard) again means software-based key protection with no HSM boundary and no automatic rotation. Thus, despite the correct encryption mechanism, the key store fails the hardware-backed security requirement and also lacks the rotation capability expected.

Azure SQL Database with geo-restore

Why it fails: Geo-restore is used for disaster recovery by restoring a database from a geo-redundant backup but does not provide continuous replication or a readable secondary.

Azure SQL Database with active geo-replication

Why it fails: Active geo-replication provides a readable secondary but does not support automatic failover; failover must be initiated manually, which does not meet the automatic failover requirement.

Azure SQL Managed Instance with failover groups

Why it fails: Azure SQL Managed Instance with failover groups is for Managed Instance, not Azure SQL Database; the question specifies SQL Server databases migrating to Azure, but the correct service for the given requirements is Azure SQL Database with failover groups.

Azure Bastion for database access and Azure Front Door for web access

Why it fails: Azure Bastion is a managed jump-host that provides secure RDP/SSH access to virtual machines for administrative management; it does not carry application traffic like HTTP or API calls and cannot serve as an internet-facing load balancer. Azure Front Door, while a global Layer-7 accelerator and load balancer, lacks the ability to filter traffic between the web and database subnets or act as a subnet-level security boundary. Together they fail to provide the required application routing to the web tier and the necessary database subnet isolation; they also add significant cost and operational overhead without solving the actual connectivity and security needs.

Azure Front Door with private link for the web tier and service endpoints for the database tier

Why it fails: Service endpoints expose the database tier to the whole virtual network, not only the web tier, so the isolation requirement fails. It is tempting as a low-overhead PaaS control, but private endpoints or NSG-scoped subnet rules are needed to restrict access to the web tier alone.

Azure Firewall in a hub VNet with forced tunneling for all traffic

Why it fails: Azure Firewall in a hub VNet with forced tunneling is a centralized managed firewall that can inspect and log traffic, but for a simple two-tier app, it requires a hub-and-spoke topology and custom User-Defined Routes (UDRs) to steer traffic through the firewall, adding complexity, latency, and cost. The requirement is only to expose the web tier to the internet and allow the database subnet to accept traffic exclusively from the web subnet; this can be achieved with an Application Gateway and NSGs, which provide the identical security boundary without the overhead of forced tunneling. Forcing all traffic through Azure Firewall also means the database subnet's east-west traffic is needlessly inspected, which is not required by the stated security need. Thus, the solution is overengineered for the problem and less efficient than a straightforward subnet-level NSG approach.

Conditional Access policies

Why it fails: Conditional Access policies enforce conditions for sign-in and access, such as requiring MFA, device compliance, or location-based constraints. They do not create administrative scopes or delegate admin rights; they regulate how every user accesses resources, so they cannot limit which subsidiary an administrator can manage. An admin assigned a directory role remains effective throughout the entire tenant, regardless of Conditional Access.

Microsoft Entra B2B collaboration

Why it fails: Microsoft Entra B2B collaboration is designed for external identities—users from other organizations—who are invited into your tenant to collaborate with their own credentials. Subsidiaries are internal sub-entities of your organization, not external parties, so B2B neither brings them into your internal identity structure nor provides any administrative scoping for delegation. Using B2B for internal subsidiaries would fragment identity management and fail to create the required subsidiary-level admin boundaries.

Custom directory roles

Why it fails: Custom directory roles allow you to define a precise set of permissions, such as resetting a user's password or managing application registrations, but the role itself has no inherent scope. Without an administrative unit, a custom role assigned to a user applies tenant-wide, which would not restrict administration to a specific subsidiary. While you can combine a custom role with an administrative unit to achieve scoped delegation, the custom role alone is insufficient for the requirement—administrative units provide the scoping mechanism.

Refactor the application to run in Azure Kubernetes Service (AKS)

Why it fails: Refactoring the application to run in Azure Kubernetes Service (AKS) requires containerizing each component, redesigning configuration management, and adapting stateful portions to Kubernetes persistent volumes and orchestration. That is a substantial development and operations effort, not a simple migration, and it introduces new skills and operational complexity. Because the goal is to move a legacy application with minimal change, this option is too invasive and would require rewriting or repackaging the application.

Migrate the file share to Azure NetApp Files

Why it fails: Migrating the file share to Azure NetApp Files is not a complete migration strategy for the monolithic application itself, which requires hosting alongside its low-latency file system. While Azure NetApp Files offers high-performance, low-latency shared file storage (NFS and SMB), making it suitable for demanding enterprise workloads, it primarily addresses the storage component. It would be an excellent choice for migrating the file share when the application is rehosted to Azure Virtual Machines, particularly for performance-sensitive applications like SAP or high-performance computing, where its capabilities would directly benefit the application's I/O requirements.

Rearchitect the application to use a microservices architecture

Why it fails: Rearchitecting the application into a microservices architecture means breaking the monolith into many independently deployable services with separate data stores, APIs, and communication mechanisms. That requires extensive code rewrites, introduces distributed data consistency and network resilience issues, and demands new deployment and monitoring tooling. For a legacy system where minimal changes are desired, this is the most disruptive and expensive strategy, far beyond a simple migration.

Azure Application Gateway

Why it fails: Application Gateway is a regional layer-7 load balancer; it cannot span two Azure regions or redirect traffic during a regional outage by itself. It fits distributing HTTP traffic across availability zones within one region, where cross-region failover is handled separately.

Availability Sets

Why it fails: Availability Sets are a regional construct that protect against rack-level failures within a single datacenter. They do not offer cross-region failover and are not sufficient for the requirement.