Chapter 3

Core Azure Services: Compute, Network, and Storage

Microsoft Azure Fundamentals (AZ-900) Study GuideBased on the Microsoft AZ-900 exam objectives

If Chapter 1 gave you the map of Azure's geography (regions, zones, resource groups) and Chapter 2 walked you through the identity system that guards the front door, this chapter is where you step inside the building and start using the rooms. Compute, networking, storage, and databases are the four pillars of every real workload you'll ever encounter in Azure — and together they make up the heart of the largest exam domain on the AZ-900, "Describe Azure architecture and services."

Here's the important thing to understand before we dive in: the AZ-900 doesn't expect you to configure any of these services. Nobody is going to ask you to write the PowerShell command that deploys a virtual machine. What the exam does expect is that you can look at a scenario — "a company needs to run a web application that scales automatically during business hours" — and pick the right service from a list. That means your job in this chapter is to understand what each service is, what problems it solves, and how it differs from the services next to it. The exam lives in those differences.

Let's start with the most familiar one: compute.

Compute Services: Where Your Code Runs

Every application needs somewhere to execute. In the on-premises world, that meant buying a physical server, racking it, cabling it, and maintaining it. In Azure, compute is abstracted into layers — you choose how much control you want and how much responsibility you're willing to hand to Microsoft. That sliding scale, from "I manage everything" to "I manage almost nothing," is the single most important mental model for the compute section of the exam.

Azure Virtual Machines

Azure Virtual Machines — VMs — are the closest thing in the cloud to the physical servers IT professionals have managed for decades. A VM is a software emulation of a physical computer: it has virtual CPUs, virtual RAM, virtual disks, and virtual network cards, and you install an operating system on it (Windows Server or Linux) exactly the way you would on real hardware. From inside the operating system, the VM feels like a real machine. You can install anything, configure anything, and break anything.

The trade-off is responsibility. With a VM, you own the operating system: patching it, hardening it, installing antivirus, managing the applications on it. Microsoft owns the physical host underneath — the actual server hardware, the power, the cooling, the building. This is the classic Infrastructure as a Service (IaaS) model, and VMs are the flagship example of it on the AZ-900.

So when would you choose a VM over the higher-level options we'll cover next? The answer comes down to control. You pick VMs when you need full control over the operating system — legacy applications that require a specific OS configuration, software that must be installed with custom drivers, or workloads you're migrating from on-premises servers where you want the new environment to mirror the old one as closely as possible. That last scenario is so common it has a name: lift and shift (or rehosting). You take a workload running on a physical server in your datacenter and move it to a VM in Azure with minimal changes. It doesn't take advantage of cloud-native features, but it's fast, low-risk, and a legitimate first step into the cloud.

One more VM concept worth knowing: availability. A single VM is a single point of failure, and Azure is honest about that — the SLA for a single VM (without premium storage) is 99.9%, but you get 99.95% or 99.99% when you spread VMs across availability zones or use availability sets. The exam occasionally asks what you need for a higher SLA, and the answer is always some form of distributing VMs so that a single hardware failure can't take them all down.

Virtual Machine Scale Sets

Now imagine you run a web application on VMs, and traffic spikes every weekday at 9 AM. You could buy bigger VMs (scaling up), but there's a limit to how big one machine gets — and you're paying for that capacity 24/7 even when nobody's using it. The smarter approach is scaling out: run more copies of the same VM when demand rises, and shut the extras down when demand falls.

That's exactly what Virtual Machine Scale Sets do. A scale set is a group of identical, load-balanced VMs that Azure automatically adds to or removes based on rules you define — CPU usage above 70% for ten minutes? Add two more VMs. Traffic drops at night? Scale back down to the minimum. You define the VM image once, and Azure handles the fleet.

The key word is identical. Scale sets are for stateless workloads where every instance is interchangeable — web front ends, batch processing workers, API servers. You would not put a database in a scale set, because databases hold state and each copy would diverge. Scale sets are also the backbone of many autoscaling scenarios the exam describes.

Azure App Service

Move one step up the abstraction ladder and you reach Azure App Service, Microsoft's fully managed platform for hosting web applications. With App Service, you don't manage VMs at all — there's no operating system for you to patch, no server to monitor. You deploy your code (a .NET app, a Node.js site, a Python API, a WordPress blog), and Azure runs it on infrastructure it manages behind the scenes. You choose a plan that determines performance and features, but the servers themselves are invisible to you.

This is Platform as a Service (PaaS): Microsoft manages the OS, the runtime, and the infrastructure; you manage your application and its data. The payoff is dramatic — deploying a web app can take minutes, scaling is built in, and built-in features like continuous deployment from GitHub, staging slots (test your new version on a staging URL, then swap it into production with zero downtime), custom domains, and TLS certificates come standard.

App Service is the right choice for standard web applications and APIs where you don't need OS-level control. If someone says "we need to host our company website and we don't want to manage servers," App Service is the textbook answer.

Containers: Azure Container Instances and Azure Kubernetes Service

Before we talk about the two container services, let's make sure containers themselves are clear — because the AZ-900 expects you to know what a container is at a conceptual level.

A container is a lightweight, portable package that holds an application and everything it needs to run: the code, the runtime, the libraries, the settings. Unlike a VM, a container doesn't carry its own operating system — it shares the host's OS kernel. That makes containers dramatically smaller and faster to start than VMs: a VM might take minutes to boot and consume gigabytes; a container starts in seconds and consumes megabytes. You can run dozens of containers on hardware that would only support a few VMs.

Think of it this way: VMs are like separate houses, each with its own foundation, plumbing, and electrical system. Containers are like apartments in one building — they share the foundation and infrastructure, but each apartment is still a private, isolated living space.

Azure Container Instances (ACI) is the simplest way to run containers in Azure. You give Azure a container image, tell it how much CPU and memory the container needs, and Azure runs it. No orchestration, no clusters, no management overhead. ACI is perfect for simple, short-lived, or bursty container workloads: a background job that runs for twenty minutes, a test environment you spin up and tear down, a single containerized API that doesn't need complex scaling.

Azure Kubernetes Service (AKS) is the other end of the spectrum: a fully managed Kubernetes orchestration platform. Kubernetes is the industry-standard system for running containers at scale — hundreds or thousands of containers across many machines, with automatic scaling, self-healing (if a container crashes, Kubernetes restarts it), rolling updates, and load balancing. Managing Kubernetes yourself is notoriously complex; AKS handles the control plane (the brains of the cluster) so you only manage your worker nodes and workloads.

For the AZ-900, you don't need to know Kubernetes internals. You need to know the decision rule: ACI for simple, individual containers; AKS for orchestrating many containers at scale.

Azure Functions: Serverless Compute

Azure Functions takes abstraction to its logical extreme: you don't manage servers, you don't manage containers, you don't even think about infrastructure. You write a small piece of code — a function — that runs in response to an event, and Azure executes it. A file lands in storage? Run the function. An HTTP request arrives? Run the function. A timer fires every hour? Run the function. A message appears in a queue? Run the function.

This is serverless computing, and the name is slightly misleading — there are servers, but they're entirely Microsoft's problem. You never provision them, never patch them, never scale them. Azure automatically runs as many copies of your function as needed and scales to zero when there's nothing to do. And the pricing matches that model: with the Consumption plan, you pay only for the time your code actually executes, measured in milliseconds. Code that runs for 200 milliseconds a few times a day costs essentially nothing.

Functions are ideal for event-driven, short-running tasks: processing uploaded images, responding to IoT sensor data, running scheduled cleanup jobs, gluing services together. They're a poor fit for long-running processes or workloads that need constant, predictable capacity — that's what VMs and App Service are for.

Choosing the Right Compute Option

Let's tie the compute family together, because the exam's favorite trick is giving you a scenario and four compute services as options. Here's the decision framework:

• Need full OS control, custom software, or lift-and-shift migration? → Virtual Machines (IaaS)
• Need many identical VMs that scale automatically with demand? → VM Scale Sets
• Need to host a web app or API without managing servers? → App Service (PaaS)
• Need to run a single container simply, without orchestration? → Container Instances
• Need to orchestrate many containers or microservices at scale? → Kubernetes Service (AKS)
• Need event-driven code that runs without any infrastructure management? → Functions (serverless)

Notice the pattern: as you move down the list, you trade control for convenience. VMs give you maximum control and maximum responsibility; Functions give you minimum control and minimum responsibility. Every scenario question is really asking: where on this spectrum does this workload belong?

Networking Services: Connecting It All Together

Compute without networking is a computer with no cables — technically running, practically useless. Azure's networking services recreate everything a physical network does (and several things it can't), inside software. The foundation of it all is the virtual network.

Virtual Networks and Subnets

An Azure Virtual Network (VNet) is your private, isolated network inside Azure — the cloud equivalent of the LAN in your office. Resources you deploy into a VNet (VMs, for example) can communicate with each other privately, and you control exactly who can reach them from outside. Every VNet has an address space — a range of private IP addresses (like 10.0.0.0/16) — from which its resources draw their addresses.

Within a VNet, you carve the address space into subnets: smaller segments that let you organize and isolate. A classic pattern is putting web servers in one subnet, application servers in another, and databases in a third. Subnets let you apply different security rules to different tiers of your application — the database subnet, for instance, might only accept traffic from the application subnet and nothing else.

VNet Peering

What happens when you have two VNets that need to talk to each other? By default, VNets are isolated — that's the point. VNet peering connects two VNets so resources in each can communicate privately, as if they were one network. Traffic between peered VNets stays on Microsoft's private backbone; it never traverses the public internet.

Peering is the standard answer whenever a scenario involves connecting VNets — whether they're in the same region or different regions (that's global VNet peering). It's simple, low-latency, and far easier than the old alternative of setting up VPN gateways between VNets.

VPN Gateway and ExpressRoute: Connecting to On-Premises

Most companies adopting Azure don't start from zero — they have existing datacenters, and they need those on-premises networks to connect securely to their Azure VNets. Azure offers two ways to build that bridge, and understanding the difference between them is one of the highest-value facts in this chapter.

VPN Gateway creates an encrypted connection over the public internet between your on-premises network and Azure. It uses the same IPsec/IKE protocols as traditional site-to-site VPNs. It's quick to set up, inexpensive, and perfectly adequate for many scenarios — but because it travels over the public internet, its bandwidth and latency are variable. Think of it as a secure tunnel through public roads.

ExpressRoute is the premium alternative: a private, dedicated connection between your network and Microsoft's network, typically provisioned through a connectivity provider. Traffic never touches the public internet at all. That means consistent, predictable latency, higher bandwidth (up to 100 Gbps), and stronger security and compliance properties. The trade-off is cost and lead time — ExpressRoute circuits take weeks to provision and cost significantly more than a VPN gateway.

The decision rule the exam wants you to internalize: VPN Gateway for encrypted connectivity over the internet (cheaper, faster to deploy); ExpressRoute for private, dedicated connectivity that bypasses the internet (predictable performance, higher security, higher cost).

Azure DNS

Azure DNS is Microsoft's managed Domain Name System service — the system that translates human-readable names (like www.contoso.com) into IP addresses. You host your DNS zones in Azure, and Microsoft's global network of name servers answers queries with high availability and fast response times.

For the AZ-900, that's genuinely the whole story: Azure DNS hosts DNS domains and resolves names. The exam might ask which service you'd use to host a company's public DNS zone, and the answer is Azure DNS. There's a private variant (Private DNS zones) for name resolution inside VNets, but at the fundamentals level, just know that Azure DNS = managed DNS hosting.

Load Balancing: Load Balancer and Application Gateway

When you scale out — running multiple copies of an application, like in a VM scale set — you need something to distribute incoming traffic across those copies. Otherwise clients would have to pick a server themselves, and a failed server would mean failed requests. That distributor is a load balancer, and Azure offers two main ones. The exam expects you to know which operates at which level.

Azure Load Balancer works at Layer 4 of the OSI model — the transport layer. It distributes traffic based on IP address and port (TCP/UDP), without looking inside the actual requests. It's fast, simple, and protocol-agnostic: it doesn't care whether the traffic is HTTP, a database protocol, or a custom application protocol. Load Balancer comes in two flavors: public (distributes internet traffic to your VMs) and internal (distributes traffic within a VNet). If you need raw, high-throughput distribution of network traffic, this is the tool.

Azure Application Gateway works at Layer 7 — the application layer. It understands HTTP and HTTPS, which means it can make smarter routing decisions: send /images/ requests to one set of servers and /api/ to another (URL-based routing), route based on the hostname, or terminate TLS (handle the encryption so your backend servers don't have to). It also includes a Web Application Firewall (WAF) option that inspects traffic for common attacks like SQL injection.

The Layer 4 vs. Layer 7 distinction is the whole game here:

NAT Gateway

Azure NAT Gateway solves a specific, practical problem: resources in a private subnet need to reach the internet (to download updates, call external APIs) but shouldn't be reachable from the internet. NAT Gateway gives all the resources in a subnet a shared, predictable outbound public IP address. Outbound traffic flows through it; inbound unsolicited traffic is blocked.

Before NAT Gateway existed, people used workarounds like assigning public IPs to load balancers for outbound connectivity. NAT Gateway is simpler, more scalable, and gives you a single static IP that external services can allowlist. For the exam, remember: NAT Gateway = controlled outbound internet access for private resources.

Network Security Groups (Conceptual)

Network Security Groups (NSGs) are Azure's basic firewall: ordered lists of allow/deny rules based on source, destination, port, and protocol, attached to subnets or individual network interfaces. "Allow HTTPS from the internet to the web subnet; deny everything else" is a typical NSG rule set.

At the AZ-900 level, you just need the concept: NSGs filter network traffic to and from Azure resources. (You'll notice we also mentioned Application Gateway's WAF — that's a specialized, application-layer firewall for web traffic, while NSGs are the general-purpose network-layer filter. The exam occasionally probes whether you know both exist.)

Storage Services: Where Your Data Lives

Every application we've discussed — VMs, web apps, functions — needs somewhere to put data that survives restarts. Azure's storage story is richer than most newcomers expect, because "storage" isn't one thing: a virtual machine's operating system disk, a photo uploaded by a user, a shared file folder, and a message queue between services all have different access patterns, and Azure gives each a purpose-built home. The exam rewards you for knowing which home fits which data.

Storage Accounts: The Container for Everything

Almost all Azure storage starts with a storage account: a uniquely named container (like contosodata2026) that holds your storage resources and controls their settings — where the data physically lives (region), how it's replicated (more on that shortly), and which services are enabled. Think of the storage account as the filing cabinet; the individual services inside are the drawers.

The Five Storage Services: Blob, Disk, Files, Queues, Tables

This is the taxonomy the exam cares about most in the storage section. Five services, five purposes:

Azure Blob Storage is object storage for unstructured data — the cloud's giant attic. Images, videos, documents, backups, log files, and data-lake files all live happily in Blob storage. "Blob" stands for binary large object, and the service is optimized for massive scale: a single storage account can hold exabytes. Blobs come in three flavors — block blobs (the default, for discrete files like images and videos), append blobs (optimized for data you add to over time, like logs), and page blobs (for random read/write workloads — and notably, the backing store for VM disks). For the exam, the headline is: Blob = unstructured object data at massive scale.

Azure Disk Storage provides the virtual hard drives that attach to VMs — the OS disk your VM boots from and any extra data disks. Disks come in SSD and HDD varieties with different performance tiers (Standard HDD, Standard SSD, Premium SSD, Ultra Disk), and you pick based on the IOPS and throughput your workload needs. The key distinction: Disks are attached to VMs; Blobs are accessed over the network by applications. A VM's C: drive is Disk storage. A photo served by a web app is Blob storage.

Azure Files offers fully managed SMB/NFS file shares in the cloud — the equivalent of the shared network drives (like \\server\share) that offices have used for decades. Multiple VMs can mount the same Azure Files share simultaneously, and you can even map it from on-premises machines. The signature scenario: "lift and shift" a legacy application that expects a traditional file share, without rearchitecting it. If the scenario mentions file shares, SMB protocol, or multiple machines needing shared file access, think Azure Files.

Azure Queue Storage is a message queue: a place for one part of an application to leave messages for another part to pick up later. A web frontend takes an order and drops a message in the queue; a background worker (maybe an Azure Function) picks it up and processes it. Queues decouple components so they don't have to run at the same time or know about each other directly. The exam-level concept: Queue = messaging between application components.

Azure Table Storage is a NoSQL key-value store — a simple, schemaless table for structured data that doesn't need the full power (or cost) of a relational database. Think user preferences, device metadata, address books: data with a natural key, accessed by that key, at massive scale and low cost. The exam-level concept: Table = NoSQL key-attribute data store.

Here's the quick-reference the exam is really testing:

Storage Tiers: Hot, Cool, Cold, and Archive

Not all data is equally urgent. The photo a user uploaded five minutes ago gets requested constantly; the compliance backup from 2019 might never be read again — but regulations say you must keep it. Charging the same price for both would be wasteful, so Blob storage offers access tiers that trade retrieval speed and cost:

• Hot: for data accessed frequently. Highest storage cost, lowest access cost, instant retrieval. The default.
• Cool: for data accessed infrequently (stored 30+ days, read occasionally). Lower storage cost, higher per-read cost, still instant retrieval.
• Cold: for data rarely accessed (stored 90+ days). Lower still on storage, higher on access.
• Archive: for data almost never accessed (stored 180+ days, like compliance archives). Cheapest storage by far — but retrieval takes hours (you must "rehydrate" the blob to Hot or Cool first) and costs the most per retrieval.

The mental model: you're sliding along a spectrum from "expensive to store, cheap to read" (Hot) to "cheap to store, expensive and slow to read" (Archive). The exam tests whether you can match a data lifecycle to the right tier.

Storage Redundancy: LRS, ZRS, GRS, and RA-GRS

Storing data once is gambling. Azure replicates every piece of storage-account data automatically — the question is just how many copies and how far apart. That's what the redundancy options control, and they're configured on the storage account:

• LRS (Locally Redundant Storage): 3 copies within a single datacenter. Cheapest. Protects against drive or rack failure — but a datacenter-level event (fire, flood) loses your data. 99.9% durability SLA (11 nines of durability, actually — 99.999999999% — but the lowest availability SLA of the options).
• ZRS (Zone-Redundant Storage): 3 copies across three availability zones in the region. Survives a datacenter failure. The sweet spot for most production data in a single region.
• GRS (Geo-Redundant Storage): 6 copies — 3 in the primary region (like LRS) plus 3 in a paired secondary region hundreds of miles away. Survives a regional disaster. There's a catch: in a regional outage, Microsoft decides when to fail over; you can't trigger it yourself.
• RA-GRS (Read-Access Geo-Redundant Storage): everything GRS has, plus read access to the secondary-region copy at all times. Your application can read from the secondary even when the primary is healthy — useful for read-heavy global workloads and for verifying your backups actually exist.

The progression is cost and protection rising together: LRS → ZRS → GRS → RA-GRS. Each step adds a wider failure domain it can survive.

Moving Data: AzCopy, Storage Explorer, and Azure Migrate

Knowing where data lives is half the battle; getting it there is the other half. Three tools cover the migration story at the AZ-900 level:

• AzCopy is a command-line utility for copying data into, out of, and between storage accounts — fast, scriptable, resumable. Think of it as the power tool for bulk blob and file transfers.
• Azure Storage Explorer is the graphical equivalent: a free desktop application for browsing storage accounts, uploading and downloading blobs and files, and managing queues and tables visually. Same job as AzCopy, but point-and-click instead of command-line.
• Azure Migrate is the bigger-picture service: it assesses your on-premises servers, databases, and applications and orchestrates their migration to Azure — including moving VMs and their data. Where AzCopy moves files, Azure Migrate moves workloads.

Database Services: Choosing the Right Data Home

We've covered where files and objects live. But applications also need databases — structured, queryable, transactional data stores. Azure offers managed database services for every major database family, and the AZ-900 expects you to know which family fits which scenario. The unifying theme: these are all PaaS — Microsoft handles patching, backups, and high availability; you handle your data and queries.

Azure SQL Database

Azure SQL Database is the managed version of Microsoft SQL Server — the relational database that has powered Windows-centric enterprises for decades. It's a full relational database (tables, rows, SQL queries, transactions, joins) delivered as PaaS: automatic backups, built-in high availability, and scaling without managing a server.

Choose it when: the workload is relational, the team knows SQL Server, or you're migrating an existing on-premises SQL Server database to the cloud with minimal changes. There's also Azure SQL Managed Instance, which is even closer to on-premises SQL Server (near-100% compatibility) for lift-and-shift database migrations — but at the AZ-900 level, knowing that Azure SQL Database = managed relational SQL Server is sufficient.

Azure Cosmos DB

Azure Cosmos DB is Azure's flagship NoSQL database — and one of Microsoft's most distinctive services. It's a globally distributed, multi-model database: your data is automatically replicated to any Azure regions you choose, and your application reads from the nearest one with single-digit-millisecond latency anywhere on earth. It supports multiple APIs (SQL-like, MongoDB, Cassandra, Gremlin for graphs, Table) so teams can use the data model that fits.

The signature scenario: a global application needing low-latency reads and writes everywhere — a worldwide e-commerce site, a multiplayer game, an IoT platform ingesting data from every continent. No other Azure database offers turnkey global distribution like Cosmos DB.

Azure Database for MySQL and PostgreSQL

Not every team runs on Microsoft's database stack. Azure Database for MySQL and Azure Database for PostgreSQL are fully managed PaaS versions of those popular open-source relational databases — automatic patching, backups, and scaling, without managing the server.

Choose them when: the application was built for MySQL or PostgreSQL (common for apps coming from Linux/open-source backgrounds, or lift-and-shift migrations of existing MySQL/Postgres databases). The decision rule is simple: match the managed service to the database engine the application already uses. Migrating a MySQL app to SQL Database would mean rewriting queries; using Azure Database for MySQL means changing almost nothing.

Here's the database decision framework:

• Relational, SQL Server-based, or migrating from on-premises SQL Server? → Azure SQL Database
• Globally distributed, low-latency-everywhere, NoSQL/multi-model? → Cosmos DB
• Built for MySQL or PostgreSQL already? → Azure Database for MySQL / PostgreSQL

Putting It All Together

Let's step back and see the chapter as a whole, because the exam doesn't test these services in isolation — it tests whether you can assemble them into solutions.

Picture a typical scenario question: "A company is migrating its on-premises e-commerce application to Azure. The application runs on Windows VMs, uses a SQL Server database, stores product images, and experiences traffic spikes during holiday sales." The AZ-900 answer assembles itself from this chapter: VMs (lift-and-shift the Windows workload, IaaS because they need OS control) → VM Scale Sets (handle the holiday spikes with automatic scaling) → Azure SQL Database (managed home for the SQL Server data) → Blob Storage in the Hot tier (product images, frequently accessed unstructured data) → Load Balancer (distribute traffic across the scaled VMs) → and an NSG filtering traffic to the web tier.

Every element of that answer came from a decision rule in this chapter. That's the skill the exam is building: not memorizing service names, but matching workload requirements to service capabilities. When you practice, cover the service names and ask yourself: "What problem does this solve, and what would make me choose it over its neighbors?" If you can answer that for every service here, you're ready.

End-of-Chapter Test

1. A company wants to migrate its on-premises application to Azure with minimal changes. The application requires custom software installed at the operating system level. Which compute service should they choose?

A. Azure App Service B. Azure Functions C. Azure Virtual Machines D. Azure Container Instances

2. A web application experiences predictable traffic spikes every weekday morning. The company wants Azure to automatically add identical virtual machines during spikes and remove them when demand falls. Which service meets this requirement?

A. Azure Virtual Machines B. Virtual Machine Scale Sets C. Azure App Service D. Azure Kubernetes Service

3. A developer needs to run small pieces of code in response to files being uploaded to storage. The company wants to pay only for the time the code actually executes and manage no infrastructure. Which service should they use?

A. Azure App Service B. Azure Functions C. Azure Container Instances D. Virtual Machine Scale Sets

4. A company needs to run a single containerized background job that executes for 20 minutes each night. They want the simplest option with no orchestration. Which service is the best fit?

A. Azure Kubernetes Service B. Azure Container Instances C. Azure App Service D. Azure Virtual Machines

5. A company has two virtual networks in Azure that need to communicate privately, with traffic staying on Microsoft's backbone network. What should they configure?

A. VPN Gateway B. ExpressRoute C. VNet peering D. NAT Gateway

6. A financial services company requires a connection between its on-premises datacenter and Azure that does NOT traverse the public internet, with predictable latency for compliance reasons. Which service should they choose?

A. VPN Gateway B. ExpressRoute C. VNet peering D. Azure DNS

7. A company needs to distribute HTTP traffic to backend servers based on URL paths (for example, /images/ to one server pool and /api/ to another), with TLS termination. Which service meets this requirement?

A. Azure Load Balancer B. Azure Application Gateway C. NAT Gateway D. Network Security Group

8. A company stores compliance backup data that is rarely accessed but must be retained for seven years. Retrieval time of several hours is acceptable. Which Blob storage tier minimizes cost?

A. Hot B. Cool C. Cold D. Archive

9. A company needs its storage data to survive the loss of an entire Azure region, and the application must be able to read data from the secondary region at all times. Which redundancy option should they choose?

A. LRS B. ZRS C. GRS D. RA-GRS

10. A legacy application being migrated to Azure requires a traditional SMB file share that multiple virtual machines can mount simultaneously. Which storage service should they use?

A. Azure Blob Storage B. Azure Disk Storage C. Azure Files D. Azure Queue Storage

11. A company is building a global e-commerce application that needs single-digit-millisecond read and write latency for users on every continent. Which database service is the best fit?

A. Azure SQL Database B. Azure Cosmos DB C. Azure Database for MySQL D. Azure Table Storage

12. A company wants to migrate its on-premises MySQL databases to Azure with minimal changes to the application. Which service should they choose?

A. Azure SQL Database B. Azure Cosmos DB C. Azure Database for PostgreSQL D. Azure Database for MySQL

---

Answer Key

1. C — Custom OS-level software requires full operating system control, which is the IaaS model: Azure Virtual Machines.
2. B — Automatically adding/removing identical VMs based on demand is the definition of Virtual Machine Scale Sets.
3. B — Event-driven code with consumption-based pricing ("pay only when code runs") and no infrastructure management is Azure Functions (serverless).
4. B — A single container with no orchestration needs points to Azure Container Instances; AKS would be overkill.
5. C — VNet peering connects two virtual networks for private communication over Microsoft's backbone.
6. B — A private dedicated connection that bypasses the public internet with predictable latency is ExpressRoute.
7. B — URL-path-based routing and TLS termination are Layer 7 capabilities: Azure Application Gateway.
8. D — Rarely accessed, retention-focused data where hours-long retrieval is acceptable belongs in the Archive tier.
9. D — Surviving regional loss requires geo-redundancy, and read access to the secondary requires the "RA" variant: RA-GRS.
10. C — Traditional SMB file shares mountable by multiple VMs is the Azure Files scenario.
11. B — Globally distributed, low-latency-everywhere NoSQL is the Cosmos DB signature scenario.
12. D — Match the managed service to the existing engine: a MySQL application belongs on Azure Database for MySQL.