Describe Azure architecture and services practice questions

Azure Virtual Machines

Why wrong: Azure Virtual Machines offer raw infrastructure with no built-in container orchestration, requiring manual installation and maintenance of the container runtime, networking, service discovery, and scaling logic. This burdens teams with tasks that a managed orchestrator would handle automatically, leading to configuration drift, increased operational complexity, and a higher risk of deployment failures. While VMs provide maximum control, they are not designed for distributed microservices workloads.

Azure Container Instances

Why wrong: Azure Container Instances launches single containers or small container groups on demand, but it lacks fundamental orchestration capabilities such as cluster-wide scheduling, automatic horizontal scaling, rolling updates, service discovery, and self-healing across a fleet of containers. It cannot coordinate the lifecycle of multiple microservices in a resilient manner, making it appropriate only for burstable, batch, or isolated workloads rather than a persistent microservices platform.

Azure App Service

Why wrong: Azure App Service is a platform-as-a-service for hosting web applications, and although it can run a single container or a Docker Compose configuration, it does not expose native Kubernetes primitives such as pods, services, ingress controllers, or cluster-wide autoscaling. It is optimized for straightforward web apps and APIs, not for coordinating independent microservices that require dynamic discovery, rolling updates, and inter-service load balancing, making it unsuitable as a microservices orchestrator.

A) Standard HDD

Why wrong: Standard HDD relies on rotating magnetic platters, delivering very low IOPS (typically around 500 max) and throughput in the tens of MB/s. This is adequate only for data archiving, backup storage, or workloads that have almost no performance requirement. A legacy application with high I/O needs would quickly saturate a Standard HDD, causing severe latency and possible application timeouts.

B) Standard SSD

Why wrong: Standard SSD uses solid-state flash but has deliberately limited performance ceilings—typically a few thousand IOPS per disk (up to 6,000 on the largest sizes) and throughput well under 1 GiB/s. It is a cost-effective upgrade from HDDs for consistent mid-level performance, but it falls far short of the sustained, mission-critical throughput needed by a legacy application with high I/O requirements. Its latency and IOPS are not in the same league as Premium or Ultra disks.

C) Premium SSD

Why wrong: Premium SSD offers strong performance—single-digit-millisecond latency and up to 80,000 IOPS per disk on the largest P80 size—and is suitable for most production workloads. However, it is still bounded by fixed performance tiers, and its throughput and IOPS peak below Ultra Disk’s sub-millisecond latency and 160,000 IOPS ceiling. For an application demanding the absolute highest performance, Premium SSD is good but not the best, making Ultra Disk the correct choice.

Standard SSD

Why wrong: Standard SSDs use solid-state drives but are backed by infrastructure that delivers only moderate, burstable performance, typically in the range of a few thousand IOPS and throughput capped well below premium tiers. They offer cost-effective storage for dev/test environments, low-traffic web servers, and lightly used production workloads, but they lack the low latency and high sustained IOPS that a high-performance database requires. For an on-premises application migrating to Azure with demanding database needs, Standard SSD would create a performance bottleneck rather than a suitable destination.

Premium SSD v2

Why wrong: Premium SSD v2 is indeed a high-performance option, providing sub-10-millisecond latency and up to 80,000 IOPS and 1,200 MBps per disk, which far exceeds Standard SSD. However, it is not the highest performance tier available; Ultra Disk offers higher maximum IOPS (300,000) and throughput (2,000 MBps), making it the superior choice when the requirement is absolute peak performance. For this question, which implicitly asks for the best possible performance, Premium SSD v2 is close but not the best, so it is incorrect.

Standard HDD

Why wrong: Standard HDD, built on spinning magnetic platters, has high latency (often tens of milliseconds) and severely limited IOPS (typically up to 2,000) and throughput. It is intended only for infrequently accessed data, backups, or non-critical workloads where cost is the primary factor and performance is secondary. Using Standard HDD for a high-performance database would result in slow queries, timeouts, and an overall inability to meet application demands, making it wholly inappropriate for the migration scenario.

Azure Kubernetes Service

Why wrong: Azure Kubernetes Service is incorrect because it introduces a full managed Kubernetes cluster, which requires maintaining node pools, networking, scaling, and upgrades even for a single container. Running one hourly 10-minute job in AKS means you are paying for and managing the underlying VMs and control plane 24/7, which is overkill and operationally complex. The scenario explicitly asks for something simple and containerized, so ACI is the lightweight alternative without the orchestration burden.

Azure Batch

Why wrong: Azure Batch is incorrect because it is designed for large-scale parallel and high-performance computing workloads, where you define a pool of compute nodes, upload task definitions, and orchestrate distributed execution across many VMs. Using Batch for a single container that runs for 10 minutes hourly would require you to allocate a pool, configure job/task structures, and manage node scheduling—far more complexity than the simple job needs. Batch is intended for batch processing with heavy parallelism, not for an isolated, periodic background task.

Azure Functions

Why wrong: Azure Functions is incorrect because, although a timer trigger can run code on a schedule, the scenario explicitly states the job is containerized. Functions does not natively execute an arbitrary container image as a standalone job; you would need to rewrite or wrap your container logic into a function runtime, which breaks the 'containerized job' requirement. While Functions supports custom containers for hosting the function app, that is not equivalent to directly running your existing container image, so ACI is the more direct and appropriate service.

Azure Blob Storage

Why wrong: Azure Blob Storage is an object storage service with a flat container/blob namespace, accessed via HTTPS/HTTP through REST APIs, SDKs, or tools—not via the SMB protocol. It does not expose a drive-addressable SMB file share, nor does it provide Windows-compatible file locking and ACL semantics for concurrent multi-VM access. As a result, Blob Storage is unsuitable for sharing a set of files over SMB and is intended for data lakes, backup, and archival workloads.

Azure Disk Storage

Why wrong: Azure Disk Storage provides block-level storage that is attached as a virtual hard disk to a single VM, not a network-facing SMB share. When a disk is attached, it appears as a raw NTFS or ext4 volume owned by one VM, and simultaneous access by multiple VMs would require Azure Shared Disks plus SCSI persistent reservations and a clustered filesystem. It lacks the SMB protocol interface and file-sharing semantics needed for the stated scenario, so it is incorrect.

Free

Why wrong: Free tier is the most limited App Service plan: it provides a shared infrastructure with strict CPU, memory, and disk quotas, and critically cannot bind a custom domain or enable HTTPS termination. Without support for custom domains or TLS, it is unsuitable for any production-facing public endpoint, and automatic scaling is not possible. Its intended use is only isolated development and smoke-testing of code, not traffic-bearing workloads.

Shared

Why wrong: The Shared tier is a step above Free: custom domains can be bound to the app, but the plan still runs on shared virtual machines and lacks both TLS/SSL termination and automatic scaling. Because HTTPS cannot be enabled at the endpoint, the mandatory HTTPS access requirement fails, and you would have to manually adjust capacity to match demand rather than relying on autoscale. This makes Shared acceptable for light production demos or intranet tools, but not for a public web app with unpredictable spikes.

Basic

Why wrong: The Basic tier supports custom domains and SSL (with SNI), but it does not support automatic scaling (autoscale). Scaling must be done manually, which does not meet the requirement for automatic scaling based on traffic spikes.

Deploy the VMs across three Availability Zones (Zone 1, Zone 2, and Zone 3) within the region.

Why wrong: Availability Zones provide resilience by placing VMs in separate physical datacenters within a region. However, the requirement is for protection within a single region without specifying multi-datacenter redundancy. Availability Zones incur higher cost and are overkill when the goal is simply to protect against failures within one datacenter. Moreover, Availability Zones are not available in all regions, and they require each VM to be in a different zone to protect against zonal failures, which is more than what is needed.

Configure a single Virtual Machine Scale Set that includes all the VMs for all three tiers.

Why wrong: A Virtual Machine Scale Set is designed to deploy and manage a set of identical, load-balanced VMs (e.g., for stateless web servers). It does not natively handle different application tiers (web, app, database) as a single set because each tier requires separate configurations, network security rules, and scaling policies. Additionally, a scale set does not inherently provide the fault and update domain isolation that an availability set offers for ensuring at least one VM per tier survives failures.

Use a Virtual Machine Scale Set with autoscale configured to always keep a minimum number of VMs running.

Why wrong: Autoscaling adjusts the number of VM instances based on demand, but it does not protect against hardware failures or planned maintenance. If a VM hosting a critical application component fails, autoscale may eventually replace it, but during the failure, availability is compromised. Furthermore, autoscaling does not guarantee that at least one VM in each specific tier remains available simultaneously, as it treats all VMs as identical.

Azure VPN Gateway (site-to-site)

Why wrong: Azure VPN Gateway (site-to-site) creates an IPsec tunnel over the public internet. Although the traffic is encrypted, it still traverses shared internet infrastructure, so it cannot provide a dedicated, private path with guaranteed bandwidth or consistent latency. This makes it unsuitable for a critical line-of-business workload that demands the performance and reliability of a private, dedicated connection like ExpressRoute.

Azure Virtual WAN

Why wrong: Azure Virtual WAN is a networking service that provides a unified hub-and-spoke architecture for branch connectivity. It can aggregate VPN and ExpressRoute connections, but it is not itself a dedicated private connection. It relies on underlying transport, so it does not directly satisfy the requirement for a dedicated connection that bypasses the internet.

Azure Bastion

Why wrong: Azure Bastion provides secure and seamless RDP and SSH access to virtual machines directly from the Azure portal using SSL, without exposing public IP addresses. It is a management service, not a hybrid connectivity service, and does not provide a dedicated connection to on-premises.

Azure Blob Storage

Why wrong: Azure Blob Storage is designed for unstructured object data (e.g., images, backups, logs) and does not natively support the SMB protocol required for simultaneous mounting by multiple VMs via a file system. While it can be accessed via REST APIs or with third-party tools, it is not the correct choice for a shared SMB file system in this scenario.

Azure Disk Storage

Why wrong: Azure Disk Storage provides persistent block storage for VMs, but each disk can be attached to only one VM at a time (unless using shared disks, which have limitations and are not designed for general-purpose SMB file sharing). It does not support simultaneous mounting by multiple servers as a shared file system.

Azure NetApp Files

Why wrong: Azure NetApp Files is tempting as it provides high-performance SMB file shares, is fully managed, and supports hybrid access. However, for a general-purpose shared file system for Windows Server virtual machines primarily needing SMB and hybrid connectivity, it is an over-provisioned and more costly solution. Azure Files offers a more direct and cost-effective managed service for this specific SMB-based Windows file share requirement, including hybrid connectivity, without the need for the extreme performance capabilities or advanced data management features unique to NetApp Files.

Azure SQL Database

Why wrong: Azure SQL Database supports active geo-replication, which allows reads from secondary replicas and automated failover, but it is fundamentally a single-writer database: all writes must go to the primary region, and secondaries are read-only. While you can manually promote a secondary, this does not allow concurrent multi-region writes or automatic conflict resolution across independent write locations, so it would bottleneck catalog updates to one region.

Azure Database for PostgreSQL

Why wrong: Azure Database for PostgreSQL can be configured with cross-region read replicas, but writes are always directed to the primary server; replicas are read-only copies and cannot accept write traffic. This architecture supports read scale-out and disaster recovery, but does not support multi-region writes, so it fails the requirement for a globally updatable product catalog without incurring latency from routing all writes to a single region.

Azure Cache for Redis

Why wrong: Azure Cache for Redis is an in-memory key-value cache, not a durable database. It is designed for transient data such as sessions or frequently accessed query results, and does not provide multi-region write replication with conflict resolution; even with Redis Enterprise features, its persistence is optional and data can be lost on scaling events without a backing database. Using it for a product catalog would risk data loss and lack the durability guarantees required for e-commerce.

Azure Blob Storage

Why wrong: Azure Blob Storage is designed for unstructured object data and does not natively support the SMB protocol. While it can be accessed via REST APIs, it cannot be directly mounted as an SMB file share by multiple VMs without additional services like Azure Files or third-party gateways.

Azure Disks

Why wrong: Azure Disks provide persistent block storage for Azure virtual machines, but each disk can only be attached to a single VM at a time. They do not support simultaneous mounting by multiple VMs, so they are unsuitable for a shared file server scenario.

Azure NetApp Files

Why wrong: Azure NetApp Files is a premium, high-performance service designed for demanding enterprise workloads requiring extremely low latency and high throughput, such as databases or SAP. While it supports SMB and is fully managed, its advanced capabilities and associated cost are excessive for the scenario's stated need for general-purpose shared documents and minimising management overhead. It would be the correct choice if the question specified extreme performance, low latency, or specific throughput requirements for critical applications, where its enterprise-grade features are essential.

Azure Load Balancer

Why wrong: Incorrect. Azure Load Balancer distributes incoming traffic within a single Azure region, not across multiple regions. It does not provide latency-based routing across regions.

Azure Application Gateway

Why wrong: Incorrect. Azure Application Gateway is a regional web traffic load balancer that operates at the application layer (HTTP/HTTPS). It does not offer cross-region latency-based routing or automatic failover across regions.

Azure Front Door

Why wrong: Azure Front Door is tempting as it provides global, performance-based routing and automatic failover for web applications, aligning with the requirements for lowest latency and regional resilience. However, for distributing traffic to virtual machines across Azure regions primarily based on user proximity and health at the DNS level, Azure Traffic Manager is the more direct and appropriate solution. Front Door, while capable, is a Layer 7 service offering advanced features like WAF and CDN integration, which are not specified as requirements here.

Azure Load Balancer

Why wrong: Azure Load Balancer is a layer 4 (transport) service that forwards traffic based on IP address and TCP/UDP port without inspecting packet contents. It cannot terminate SSL, perform HTTP header inspection, or route by URL path because it operates below the application layer. While it efficiently distributes raw network traffic across VMs, it lacks the application-aware features needed for intelligent routing of web traffic.

Azure Application Gateway

Why wrong: Azure Application Gateway is a regional layer 7 (application) load balancer designed specifically for HTTP/HTTPS traffic. It supports SSL termination, URL-based path routing, multi-site hosting, and a built-in Web Application Firewall (WAF) that protects web applications from common exploits. For use cases requiring deep inspection of web requests and centralized SSL management, Application Gateway is the correct Azure service.

Azure Traffic Manager

Why wrong: Azure Traffic Manager operates at the DNS level, directing client requests to different regional service endpoints based on routing methods such as performance, priority, or geographic location. It does not act as a reverse proxy, so it cannot terminate SSL, inspect HTTP content, or apply URL-based routing rules. Traffic Manager simply returns a DNS response to steer traffic; it never handles the actual request payload, making it unsuitable for the application-layer features described.

Azure Cosmos DB for Graph

Why wrong: Azure Cosmos DB for Graph is a multi-model database service that supports the Gremlin graph query API, allowing you to build and query custom graph databases. It is a general-purpose data store for your own graph-structured data, not a service for retrieving pre-existing Microsoft 365 entities such as users, emails, or calendars. Microsoft Graph is the REST API that accesses those Microsoft services, so Cosmos DB for Graph is an incorrect choice.

Azure Active Directory Graph API

Why wrong: The Azure Active Directory Graph API was a REST API that provided access to directory data such as users, groups, and applications, but only within Azure AD. Microsoft has deprecated it in favor of Microsoft Graph, which expands coverage to all Microsoft 365 services while still including the same directory capabilities. Because it is outdated and narrower in scope, it is not the correct answer for accessing Microsoft 365 data today.

Azure API Management

Why wrong: Azure API Management is a fully managed service for creating, publishing, and securing APIs, acting as a gateway between clients and backend services. It does not provide direct access to Microsoft 365 data; rather, it helps govern and monitor APIs like Microsoft Graph through policies, throttling, and analytics. Therefore, it is a management layer, not the unified data API being asked for.

Azure App Service Editor

Why wrong: Azure App Service Editor is a browser-based file editor designed exclusively for modifying the source code of a web app hosted in Azure App Service. It cannot execute general shell commands, install packages system-wide, or run Azure management cmdlets/CLI across resources. Its scope is limited to one app's deployment files, making it a code-editing tool rather than a cloud management shell.

Azure DevOps

Why wrong: Azure DevOps is a comprehensive SaaS suite for the entire application lifecycle, including Boards, Repos, Pipelines, Test Plans, and Artifacts. While its pipelines can run Azure CLI or PowerShell tasks, those tasks are part of automated CI/CD execution on hosted agents, not an interactive browser-based shell for manual Azure management. It is a collaboration and automation platform, not the lightweight shell accessed from the portal.

Azure Sandbox

Why wrong: Azure Sandbox, as used in Microsoft Learn, is a temporary, constrained subscription created for hands-on training; it grants limited credits, auto-cleans after the module, and restricts access to certain resource types. Cloud Shell, by contrast, runs against your own permanent subscription and retains your personal files, so it is intended for real administrative work, not just lab exercises.

Azure SQL Database

Why wrong: Azure SQL Database is a fully managed relational database service based on the Microsoft SQL Server engine. It supports only the relational data model and T-SQL, with no built-in capabilities for document, graph, or key-value models (beyond limited JSON functions or graph extensions that are not true multi-model APIs). Although it offers geo-replication via failover groups, writes are always coordinated through a primary replica and there is no multi-master write capability, so it is not a multi-model globally distributed database like Cosmos DB.

Azure Database for PostgreSQL Hyperscale

Why wrong: Azure Database for PostgreSQL Hyperscale (Citus) is a distributed relational database engine that scales out PostgreSQL across multiple nodes via sharding. While it offers horizontal scaling for OLTP workloads, it remains strictly relational and supports only the PostgreSQL data model. It does not expose multiple data models such as document, graph, or key-value, nor does it provide global multi-master distribution across regions, so it cannot meet the stated multi-model global database requirement.

Azure Synapse Analytics

Why wrong: Azure Synapse Analytics is an enterprise analytics service that unifies data warehousing, big data processing, and data integration. It is optimized for OLAP workloads, running complex queries over large volumes of data, rather than for transactional, multi-model database workloads. Synapse does not support multiple data models like graph or key-value, and it lacks the global multi-master write capability needed for the scenario; it is a data warehouse, not a globally distributed multi-model database.

Zone-Redundant Storage (ZRS)

Why wrong: Incorrect. Zone-Redundant Storage (ZRS) replicates data synchronously across availability zones within a single region, but does not replicate across paired regions, so it does not provide the highest durability among options that cross regions.

Locally Redundant Storage (LRS)

Why wrong: Incorrect. Locally Redundant Storage (LRS) replicates data three times within a single data center in one region, offering the lowest durability (11 nines) and no protection against region-wide failures.

Geo-Redundant Storage (GRS)

Why wrong: Incorrect. Geo-Redundant Storage (GRS) replicates data across paired regions but within the primary region it only uses LRS, offering 12 nines durability. This is less durable than GZRS, which adds zone-redundancy in the primary region.

Azure API Management

Why wrong: Azure API Management is an API gateway service that publishes, secures, and transforms HTTP APIs, but it does not provide a runtime environment for hosting or orchestrating microservices. It sits as a facade in front of backend services, handling concerns like authentication, rate limiting, and request routing. Service Fabric, by contrast, is the underlying platform that runs and manages the microservices themselves, so API Management is a complementary layer rather than an alternative.

Azure Kubernetes Service

Why wrong: Azure Kubernetes Service (AKS) provides managed Kubernetes container orchestration, enabling deployment, scaling, and management of containerized workloads, yet it does not natively offer the rich microservices-specific features that Service Fabric provides. AKS relies on external add-ons like Helm charts and separate state stores for persistence, whereas Service Fabric includes built-in service discovery, state management, and an actor pattern. For teams needing a full microservices framework with operational simplicity, AKS is container-centric and not the same as a dedicated microservices runtime.

Azure Logic Apps

Why wrong: Azure Logic Apps is a cloud workflow service designed for integrating applications, data, and systems through prebuilt connectors and serverless orchestration. It focuses on automating business processes and integrating SaaS/enterprise solutions, not on hosting or running microservices workloads. Using Logic Apps to replace Service Fabric would mean trying to serve business logic and internal service-to-service communication with a tool built for API integration, which is a mismatch of architectural purposes.

Azure Queue Storage

Why wrong: Azure Queue Storage is a message queue service for decoupling application components through asynchronous messages. Messages are short-lived payloads that are typically retrieved and deleted after processing, so there is no mechanism to enforce write-once, read-many behavior. It lacks the immutability policies needed to guarantee that transactional records remain unchanged for legal or regulatory periods.

Azure Files

Why wrong: Azure Files offers fully managed SMB and NFS file shares that are ideal for lift-and-shift applications and shared file access. While you can set ACLs and access policies, it does not provide native immutable WORM guarantees at the file/share level. File shares are mutable by design, making them unsuitable for preserving transactional records unchanged for compliance.

Azure Data Lake Storage

Why wrong: Azure Data Lake Storage is a scale-out data lake built on Blob Storage with a hierarchical namespace, optimized for big data analytics workloads. Its core value is massive parallel throughput for batch and real-time analytics, not durable, fixed-content record storage. While it can support some immutability features as part of the underlying Blob Storage, the service is not the targeted answer for WORM-protected transactional records.

Azure Blob Storage with NFS 3.0

Why wrong: Azure Blob Storage does support NFS 3.0 on premium block blob accounts, but it is fundamentally object storage with a hierarchical or flat namespace, not a fully managed file share service. It lacks key file-share capabilities such as SMB protocol coexistence and file-level snapshots, and the older NFS 3.0 protocol does not match the NFS 4.1 support that Azure Files offers for Linux clients. Thus, while blob storage can serve Linux clients via NFS, it is not the intended solution for a high-performance shared file share.

Azure NetApp Files

Why wrong: Azure NetApp Files is an enterprise-grade, third-party NAS offering that supports both NFS and SMB, but it is a premium, dedicated capacity service requiring delegated subnets and its own networking architecture. It is designed for complex, high-performance workloads such as SAP and VDI, not for simple, cost-effective file sharing where Azure Files is the standard PaaS choice. For a basic high-performance Linux shared file share, Azure NetApp Files is unnecessarily complex and expensive compared to Azure Files with NFS 4.1.

Azure Data Lake Storage

Why wrong: Azure Data Lake Storage (ADLS) is a big-data analytics storage built on Azure Blob Storage, adding a hierarchical namespace to organize objects. It is not a file-share service and does not provide an NFS endpoint for mounting as a shared file system; access is primarily through the Blob REST API, Hadoop/Spark, and Azure Storage SDKs. ADLS Gen2 does support POSIX-like permissions but only as metadata on blob items, not as a true network file share, so it cannot serve Linux clients as a mounted NFS file system.