Azure Services practice questions

Public

Why it fails: A public cloud is provisioned entirely with a provider such as Azure, with no on-premises data centre component, so it cannot describe extending existing hardware. It would be correct when an organisation runs all workloads on shared provider infrastructure without retaining its own servers.

Private

Why it fails: A private cloud is dedicated cloud infrastructure operated for a single organisation, whether hosted on-premises or by a third party, so it excludes Azure public cloud services. It would be correct when an organisation needs sole-tenant infrastructure and does not burst into shared public capacity.

Multi-cloud

Why it fails: Multi-cloud means using two or more public cloud providers, such as Azure alongside AWS, so it does not describe connecting on-premises hardware to Azure. It would be correct when an organisation deliberately spreads workloads across providers for redundancy or to avoid vendor lock-in.

Azure Container Instances

Why it fails: Azure Container Instances (ACI) allows you to run individual containers directly without managing VMs, but it does not provide built-in orchestration, scaling, or management for multiple containers working together as a microservices application. It is best for simple, single-container tasks.

Azure App Service

Why it fails: Azure App Service is a Platform as a Service (PaaS) offering for hosting web applications, RESTful APIs, and mobile backends. While it can run containerized web apps, it is not designed to orchestrate multiple microservices as a cohesive cluster. It lacks features like service discovery and pod scheduling required for distributed container orchestration.

Azure Batch

Why it fails: Azure Batch is a job scheduling service for running large-scale parallel and high-performance computing workloads. It is not designed for managing containerized microservices and does not provide the orchestration primitives (like Kubernetes pods and services) needed for this scenario.

Elasticity

Why it fails: Elasticity refers to the ability to dynamically add or remove resources, such as virtual machines or storage, in response to fluctuating demand. While this optimizes utilization and reduces waste, it does not lower the per-unit cost of infrastructure. Elasticity improves operational agility and cost control by matching capacity to actual usage, but it is unrelated to the procurement-scale discounts that cloud providers negotiate for hardware.

High availability

Why it fails: High availability ensures that applications remain operational during failures by using redundant components, automated failover, and load balancing across fault domains. This design principle focuses on maximizing uptime and minimizing downtime, often requiring additional resources and thus higher costs. High availability does not confer purchasing power or reduce the unit price of Azure services; it is a reliability characteristic that operates independently of scale-based pricing benefits.

Geo-distribution

Why it fails: Geo-distribution is the placement of cloud resources across multiple, globally dispersed Azure regions to reduce network latency, meet data residency requirements, and improve resilience. While this offers compliance and performance advantages, it does not inherently reduce the cost of infrastructure. In fact, maintaining resources in many regions can increase operational complexity and cost, so geo-distribution is not a driver of lower per-unit pricing.

Availability Zones

Why it fails: Availability Zones are physically separate datacenters within a single Azure region. They do not span across two different regions and therefore cannot provide disaster recovery across regions or ensure data remains within a specific geography like the United States.

Resource Groups

Why it fails: Resource Groups are logical containers in Azure used to organize and manage related resources, such as grouping a virtual network and its VMs for lifecycle management. They provide no inherent disaster recovery capability, no maintenance sequencing, and no built-in replication across distinct geographic regions. A resource group simply holds resources that may be deployed to a single region, meaning it does not satisfy the requirement of being located within the same geography for recovery purposes.

Azure Policy

Why it fails: Azure Policy is an Azure governance service that evaluates and enforces compliance rules on resources (e.g., restricting resource SKUs or locations) by applying policy definitions to management groups, subscriptions, or resource groups. It is fundamentally a control-plane tool for auditing and remediation, not an infrastructure topology feature. Azure Policy cannot influence how regions are paired, which region gets prioritized for disaster recovery, or how platform updates are sequenced—those are physical and operational characteristics of Azure's region-pair architecture.

Storing all data on physical servers in the customer's own building

Why it fails: Keeping all data on physical servers in the customer's own building describes on-premises or traditional IT infrastructure, not cloud computing. Cloud services are typically hosted in provider-managed data centers, accessed over the internet, and billed on a pay-per-use basis. While a private cloud can exist on-premises, it still relies on virtualization, self-service provisioning, and automated management — simply storing data on physical servers without these capabilities is the opposite of cloud computing.

Using only virtual machines in a third-party data center

Why it fails: Virtual machines in a third-party data center are a narrow example of IaaS, but cloud computing goes well beyond VMs. Modern public clouds also provide managed databases, containers, serverless compute, AI/machine learning services, analytics, and SaaS applications delivered over the internet. Additionally, a third-party data center could simply be a colocation facility where you own and manage the hardware — that is not cloud unless it offers on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service.

A type of software that runs in web browsers without installation

Why it fails: This option describes software-as-a-service (SaaS), such as webmail or Office 365, where the application runs in a browser and requires no local install. However, cloud computing encompasses far more than SaaS — it also includes infrastructure (IaaS), platforms (PaaS), serverless functions, storage, and databases. Moreover, browser-based software can technically run on on-premises servers, so this option captures neither the full service spectrum nor the internet-delivered, consumption-based model that defines cloud computing.

Azure Resource Manager

Why it fails: Azure Resource Manager serves as the native control plane for creating, updating, and deleting resources within Azure subscriptions. Its resource providers understand only Azure-hosted services; virtual machines located on-premises or in another cloud are not registered in ARM's data model unless explicitly connected through Azure Arc. Consequently, ARM alone provides no way to apply lifecycle operations, policies, or monitoring to non-Azure servers.

Azure Blueprints

Why it fails: Azure Blueprints is an orchestration service that packages ARM templates, policies, and role assignments into a single composable environment for repeatable deployment. Its scope is strictly limited to Azure subscriptions and resource groups; it defines what gets deployed inside Azure, not how to govern existing external workloads. Because Blueprints cannot register, inventory, or apply policy to on-premises or other-cloud virtual machines, it fails as a hybrid management solution.

Azure Management Groups

Why it fails: Management Groups create a hierarchy for organizing Azure subscriptions and enabling RBAC, policy, and cost controls at scale. However, they are purely an Azure tenant-level construct: they apply to subscriptions and their native resources only. There is no mechanism in Management Groups to connect to, register, or monitor virtual machines running outside Azure, so they cannot address hybrid management needs.

Azure Load Balancer

Why it fails: Azure Load Balancer is a regional, layer 4 (TCP/UDP) load balancer that distributes incoming traffic to healthy backend instances within a single Azure region. It cannot route traffic across multiple regions, nor does it perform global DNS resolution, so it offers no cross-region failover by itself. It is typically used behind Traffic Manager when an application spans Azure regions.

Azure Application Gateway

Why it fails: Azure Application Gateway provides regional, layer 7 HTTP/S load balancing with features like cookie affinity, path-based routing, and a Web Application Firewall, but it is confined to one region and one set of backend pools. It does not have global DNS visibility or the ability to reroute users to an alternate region if the whole regional deployment becomes unhealthy. Therefore, it is an incorrect choice for multi-region failover.

Azure VPN Gateway

Why it fails: Azure VPN Gateway is a network connectivity service that establishes encrypted IPsec tunnels between on-premises locations or individual clients and an Azure virtual network. It is designed for secure site-to-site or point-to-site access, not for distributing HTTP/S application traffic or making routing decisions based on endpoint health. As such, it cannot satisfy a multi-region failover requirement.

Azure Container Instances

Why it fails: Azure Container Instances (ACI) is incorrect because it allows you to run containers quickly without managing VMs, but it lacks the orchestration features needed for a multi-service microservices architecture. ACI does not provide built-in service discovery, automated rolling updates, or replica-based auto-scaling across multiple containers, so you would need to build those capabilities yourself or integrate an external orchestrator. This makes ACI suitable for simple, isolated workloads rather than full microservices orchestration.

Azure App Service

Why it fails: Azure App Service is not the best fit because, while it can host containerized applications, it is fundamentally a PaaS service designed for web apps and APIs. App Service does not offer Kubernetes-grade orchestration features like pod scheduling, service-to-service discovery, or sophisticated rolling update strategies; it abstracts away the infrastructure but gives you less control over container placement and networking. Consequently, it works for simple containers but becomes limiting for complex, independently scalable microservices.

Azure Functions

Why it fails: Azure Functions is incorrect because it is a serverless, event-driven compute service that executes short-lived code in response to triggers like HTTP requests or queue messages. It is not designed for running long-running containerized microservices, nor does it provide container orchestration with service discovery and rolling updates. Its scaling model is per-function and trigger-based, which does not match the operational requirements of a microservices architecture where each service manages its own lifecycle and networking.

Azure Policy

Why it fails: Azure Policy is used to enforce compliance rules on existing resources (e.g., requiring tags or encryption). It cannot deploy new infrastructure, assign roles, or package multiple components into a single deployable artifact. While policies can be included in a blueprint, Azure Policy alone does not meet the full requirement.

Azure Resource Manager (ARM) templates

Why it fails: ARM templates are infrastructure-as-code files that deploy Azure resources. However, they do not natively include role assignments or policy assignments in a governance-focused way. You can embed those using nested templates and custom scripts, but ARM templates lack built-in versioning for governance artifacts and are not designed specifically as a governance packaging tool.

Azure Management Groups

Why it fails: Management Groups provide a hierarchical structure for organizing subscriptions and applying access control (RBAC) and policies at scale. They do not deploy resources or define the composition of an environment. Management Groups are used to organize subscriptions, not to package and deploy a standardized environment.

Patching the operating system of the web server

Why it fails: In Azure App Service, which is a fully managed PaaS offering, Microsoft handles all operating system patching, including security updates and bug fixes, for the virtual machines that host the web application. The customer is not allowed to log into the OS or install patches, because such access is abstracted away by the platform. The customer's only patching responsibility is for the application code, binaries, and any third-party libraries they deploy to the service. This contrasts sharply with IaaS VMs, where the customer must manage OS updates and security configurations.

Managing network security groups for the virtual network

Why it fails: In PaaS, the provider manages the network infrastructure. While customers can configure some network controls (e.g., access restrictions), the underlying network security groups are managed by Azure for the platform. The customer is responsible for configuring inbound/outbound access rules at the application level, but not the virtual network NSGs unless they integrate their own VNet.

Physical security of the Azure data center

Why it fails: Physical security of the Azure data center, including perimeters, guards, biometric access controls, and environmental safeguards, is exclusively the cloud provider's responsibility. Because the customer never receives physical or logical access to the underlying servers hosting a PaaS service like Azure App Service, there is nothing the customer can do to secure the facility itself. The provider is also responsible for compliance certifications related to physical safeguards, such as SOC 1/2 and ISO 27001. This is a clear example of 'security of the cloud' as opposed to 'security in the cloud.'

Azure Resource Health

Why it fails: Azure Resource Health is incorrect because it narrowly reports the real-time health of a specific resource instance, such as a single virtual machine or a SQL database. It tells you whether that resource is currently up, degraded, or down, and it maintains a history of past resource-level incidents. However, it contains no information about upcoming planned maintenance or other service-level advisories, so it cannot fulfill the company's requirement to report on future maintenance.

Azure Monitor

Why it fails: Azure Monitor is incorrect because it is a comprehensive telemetry and diagnostics platform that collects metrics, logs, and activity data from your resources and applications. You can use it to set performance alerts, correlate issues, and analyze application behavior, but it does not inherently include a view of Azure platform planned maintenance. Any such information would have to be obtained from outside Azure Monitor, making it the wrong tool for reporting on upcoming maintenance events.

Azure Advisor

Why it fails: Azure Advisor is incorrect because it is a proactive recommendation service that evaluates your resource configuration and usage to suggest improvements in reliability, security, performance, and cost. It does not show the current operational health of your resources nor does it list planned maintenance events. Advisor is designed for optimization of your deployments, not for monitoring service status or tracking maintenance schedules, so it is not relevant to the company's need.

Azure Reserved Instances

Why it fails: Reserved Instances are a billing and pricing model that offers discounted rates in exchange for a one- or three-year commitment. They do not provide any physical server isolation; VMs purchased under Reserved Instances may still run on shared physical hardware.

Azure Virtual Machine Scale Sets

Why it fails: Virtual Machine Scale Sets allow you to deploy and manage a group of identical, load-balanced VMs that can scale in or out automatically. They do not guarantee that the VMs are placed on a dedicated physical host; the underlying hardware may be shared with other tenants.

Azure Confidential Computing

Why it fails: Confidential computing protects data in use by using hardware-based trusted execution environments (e.g., Intel SGX). While this provides strong data encryption during processing, it does not ensure that the entire physical server is dedicated to a single customer. Multiple tenants' VMs using confidential computing can still reside on the same physical host.

Azure Functions and Azure Cosmos DB

Why it fails: Azure Functions is a serverless compute service that scales to zero and executes code on triggers; it is not intended to host an always-on web tier, because it introduces cold starts and lacks persistent application state. Azure Cosmos DB is a multi-model NoSQL database with horizontal partitioning and wire protocols for MongoDB/Cassandra, not a relational engine, so it cannot replace a SQL database for ACID-heavy transaction processing in a traditional web app.

Azure Virtual Machine Scale Sets and Azure Files

Why it fails: Azure Virtual Machine Scale Sets provide autoscaling for compute, but Azure Files offers shared file storage with latency unsuitable for transactional database workloads, which require low-latency block storage such as Azure SQL Database or managed disks. This combination tempts because Azure Files is a convenient shared storage for web-tier static content or application configuration, where throughput matters more than sub-millisecond I/O.

Azure Kubernetes Service and Blob Storage

Why it fails: Azure Kubernetes Service gives you managed Kubernetes orchestration but requires cluster management, autoscaling of pods, and more operational overhead than PaaS web hosting, making it heavier than necessary for a typical web tier. Blob Storage is object storage optimized for large amounts of unstructured data; it is accessed via REST and has higher latency per I/O than block-based database storage, so it is unsuitable for transactional workloads that require low-latency reads and writes. This pairing might be considered because AKS scales containers and Blob can hold static assets, but it does not provide a relational database tier.

Azure Container Instances

Why it fails: Azure Container Instances (ACI) can quickly run a single container or a small group of containers, but it lacks the orchestration features required for microservices. ACI does not provide built-in auto-scaling based on container metrics, service discovery across multiple instances, or rolling deployment strategies. While ACI is excellent for on-demand or event-driven scenarios, it is not a substitute for a managed Kubernetes service when you need a resilient, scalable microservices platform.

Azure Batch

Why it fails: Azure Batch is designed for large-scale parallel and high-performance computing (HPC) jobs that run to completion, such as rendering or data processing workloads. It does not run long-lived, always-on microservices, nor does it provide native service discovery or rolling updates for containerized applications. Batch is a job scheduler, not a container orchestrator, so it is fundamentally misaligned with the needs of a microservices team.

Azure Virtual Machine Scale Sets

Why it fails: Azure Virtual Machine Scale Sets (VMSS) provide automatic scaling of virtual machines, but they operate at the infrastructure level, not the container level. To use containers on VMSS, you must manually configure and manage the container runtime, and there is no built-in orchestration for service discovery, rolling updates, or inter-container networking. VMSS would require you to deploy and manage a separate orchestrator like Kubernetes yourself, which is extra overhead compared to using AKS.

Distributing compute resources across multiple virtual machines in a single data center

Why it fails: Distributing compute resources across multiple virtual machines in a single data center describes an availability set or virtual machine scale set within one Azure region or availability zone. That design provides high availability against hardware failures or updates within the same physical site, but it does not achieve geographic dispersion. Geo-distribution specifically requires deploying across distinct geographic locations, not just multiple VMs in a single data center.

Routing network traffic to the fastest available server

Why it fails: Routing network traffic to the fastest available server describes traffic manager or load-balancing functionality, such as Azure Traffic Manager or Application Gateway with latency-based routing. While this improves performance by directing users to a nearby healthy endpoint, it does not inherently copy or place applications and data across geographic regions. Geo-distribution is a deployment architecture decision, not a traffic-routing mechanism.

Encrypting data before sending it over the network

Why it fails: Encrypting data before sending it over the network is a security control, commonly implemented with TLS/HTTPS or Azure Storage service encryption, to protect data in transit from eavesdropping. This measure addresses confidentiality and integrity but has no relationship to the geographic placement of workloads. Geo-distribution is about physical resource location across the globe, not about data protection techniques.

To provide virtual machine operating system management

Why it fails: ARM manages Azure resources at the platform level, such as virtual machines, networks, and storage accounts, but it does not interact with the guest OS inside a VM. Operating system updates, application installation, and OS-level configuration are the customer's responsibility, typically handled via Remote Desktop, SSH, or tools like Azure Update Management. ARM's scope ends at the resource boundary, not the OS that runs within it.

To monitor Azure resource performance

Why it fails: Monitoring Azure resource performance is a function of Azure Monitor, which collects metrics, logs, and alerts for resources. Azure Resource Manager (ARM) is the control plane that handles provisioning, deployment, and configuration of resources, not runtime performance telemetry. ARM's role is to orchestrate the creation and management of resources, while monitoring is a separate data-plane and telemetry service.

To replicate data across Azure regions

Why it fails: Data replication across Azure regions is performed by storage services using redundancy options like GRS (geo-redundant storage) or GZRS, and by database services like Azure SQL geo-replication. ARM is a resource management API and does not move or copy data; it only handles the deployment and configuration of the services that may later replicate data. Replication is a data-plane activity, whereas ARM operates on the control plane.

A command-line tool for automating Azure resource management

Why it fails: The Azure portal is not a command-line tool; command-line automation of Azure resources is handled by Azure CLI and Azure PowerShell. These tools enable scripted, repeatable management operations via a terminal, whereas the portal is a graphical web console. The portal does not accept shell commands and is intended for point-and-click management rather than automation.

A development environment for writing and testing Azure code

Why it fails: The Azure portal is not a development environment for writing and testing code; that role belongs to tools like Visual Studio, Visual Studio Code, or Azure Cloud Shell. While Cloud Shell can be accessed from within the portal, it is a terminal, not a full integrated development environment. The portal focuses on resource management, deployment, and monitoring, not code editing or debugging as a primary function.

A marketplace for purchasing third-party software

Why it fails: The Azure portal is not a marketplace for purchasing third-party software; that is the purpose of Azure Marketplace, which offers pre-built solutions and services. Although Azure Marketplace can be accessed through the portal, the portal itself is the overall management console rather than a storefront. The portal lacks the purchasing and licensing workflows that define a marketplace, being instead the tool for managing resources after they are acquired.

Pay-as-you-go

Why it fails: Pay-as-you-go is the default pricing model with no upfront commitment or term, so you pay the full list price for each consumed resource. While it offers flexibility to scale up/down or deallocate resources at any time, it does not include the steep discount that a 1- or 3-year commitment via Azure Reservations provides. This makes it costlier for predictable, steady-state workloads.

Azure Spot pricing

Why it fails: Azure Spot pricing lets you purchase unused Azure compute capacity at deeply discounted rates, but the resources are non-resilient and can be evicted whenever Azure needs the capacity back for normal-priority workloads. Because eviction can occur with very short notice, Spot VMs are ill-suited for production or failure-tolerant workloads, whereas an Azure Reservation is a guaranteed-term commitment that never causes eviction. Spot pricing is essentially an interruptible surplus-capacity model, not an alternative to reservation pricing.

Azure Dev/Test pricing

Why it fails: Azure Dev/Test pricing offers discounted rates for virtual machines and other services specifically used in non-production development and testing scenarios, and it typically requires a Visual Studio/MSDN subscription to activate. This benefits short-lived, non-mission-critical workloads but cannot be applied to production environments or formal capacity commitments. Azure Reservations instead target production-grade workloads with an explicit 1- or 3-year term commitment, which is a fundamentally different cost-management lever.

Public cloud

Why it fails: Public cloud is a deployment model where a third-party provider owns and operates all infrastructure, delivering services over the internet to multiple tenants. There is no on-premises component or dedicated private infrastructure — the customer does not manage the underlying hardware. Because the question describes a mix of on-premises and cloud resources, public cloud alone cannot satisfy the requirement, as it lacks any private/on-premises integration.

Private cloud

Why it fails: Private cloud is an environment dedicated to a single organization, whether hosted on-premises or by a third party, but with no shared public cloud exposure or integration. It provides enhanced control and isolation, yet it does not by itself combine with public cloud services. Hybrid cloud extends private cloud by connecting it to public cloud resources to gain elasticity and scalability, so a purely private model would miss the public cloud component described.

Multi-cloud

Why it fails: Multi-cloud refers to using services from multiple public cloud providers (e.g., AWS and Azure) simultaneously, often to avoid vendor lock-in or to leverage best-of-breed capabilities. It does not inherently involve any on-premises infrastructure, whereas hybrid cloud specifically integrates a private/on-premises environment with a public cloud. The defining distinction is that multi-cloud operates entirely in public cloud footprints, whereas hybrid cloud crosses the boundary between private and public.

Azure Monitor Metrics

Why it fails: Azure Monitor Metrics aggregates telemetry into numeric performance counters such as CPU utilization, memory consumption, and request counts, giving high-level views of resource health. Because it samples and summarizes data over time intervals, it lacks the operation-level correlation identifiers needed to trace a single user request through each dependency. Consequently, while it can alert on aggregate latency changes, it cannot show the step-by-step path that a specific request takes across services.

Azure Log Analytics queries

Why it fails: Azure Log Analytics queries give you raw log access and the ability to join tables using KQL, but they do not create correlation links on their own. Without trace context embedded in each log entry—typically an operation ID from Application Insights—you would have to manually infer relationships using timestamps and custom fields, which is error-prone and incomplete. Thus Log Analytics can assist in investigating known issues but cannot automatically present the full end-to-end path of a request across distributed components.

Azure Network Watcher

Why it fails: Azure Network Watcher is designed for infrastructure-level network troubleshooting, offering tools like connection monitor, IP flow verify, and packet capture that inspect L3/L4 connectivity, routing, and NSG rules. It operates on IP packets and network interfaces rather than application-level HTTP requests or database calls, so it cannot observe the logical flow of an application request from front end to back end. As a result, it is fundamentally unable to reconstruct an individual request's distributed trace across services.