C. Separate availability zones

Azure provides multiple availability constructs, each designed to protect against a different scope of failure. As protection increases, physical distance increases, which directly impacts network latency.

• Availability Sets
  Protect against hardware failures within a single datacenter. They offer very low latency but do not survive a facility outage.
• Availability Zones
  Protect against datacenter failures. Zones are physically separate datacenters within the same Azure region, isolated for power and cooling, yet connected by high speed, low latency Microsoft fiber.
• Region Pairs
  Protect against regional disasters. Resources are replicated hundreds of miles apart, which significantly increases latency.

Protection scope increases from left to right, while network latency also increases.

In this scenario, Availability Zones are the only option that survive a full datacenter outage while still meeting the low latency requirement.

A. Separate resource groups
Resource groups are management containers. They do not control physical placement or availability.

B. Separate availability sets
Availability sets protect against rack or host failures only. They do not protect against a full datacenter outage.

D. Separate regions in a regional pair
Regional pairs introduce significant latency due to geographic distance, which violates the minimal latency requirement.

• Statement 1: Yes. Resource Groups are logical containers. The location of the container (metadata) does not dictate the physical location of the resources inside it.
• Statement 2: Yes. Resources interact via networks and APIs. They do not need to be in the same “folder” (Resource Group) to talk to each other.
• Statement 3: No. A ReadOnly lock is restrictive. It prevents both deleting and modifying resources. To allow updates but prevent deletion, you would use a CanNotDelete lock.

To master this topic, you must separate the Management Plane (The Resource Group) from the Data Plane (The Resources).

1. The “Inventory List” Analogy
Think of a Resource Group as a physical clipboard holding an inventory list.

• You can keep the clipboard in your New York office (East US Region).
• The actual equipment on the list can be stored in a warehouse in London (West Europe Region).
• Where you keep the list does not force you to move the equipment. This is why RG location and Resource location are independent.

2. Interaction Borders
Resource Groups are management boundaries, not security walls. A Virtual Machine in Group A can talk to a Database in Group B freely, provided their network settings allow it. The Resource Group does not block traffic.

Visualizing the separation between Logical Grouping and Physical Location.

B. Two

To answer this, you must solve for the “Pivot Point”: What triggers a new invoice?

1. The Billing Rule:
An Azure Subscription is a billing unit. If you need a separate invoice (a distinct document requesting payment), you must create a separate Subscription.
• Marketing needs a separate invoice → Subscription 1. • Sales and IT share an invoice → Subscription 2.

2. The Security Rule:
A Subscription is not required to separate permissions. You can place Sales resources in “Resource Group A” and IT resources in “Resource Group B” inside the same subscription. You then use Role-Based Access Control (RBAC) to build a “wall” between them.

Visualizing the separation between Billing (Subscription) and Security (RBAC) boundaries.

Total Minimum Subscriptions: 2.

A. One
This violates the billing requirement. If you put all three departments in one subscription, you generate a single invoice. Marketing would not receive their own separate bill.

C. Three
This is a valid configuration, but it is not the minimum. You could create a separate subscription for Sales and IT, but since they want to share an invoice, it adds unnecessary management overhead.

• Requirement A: Management Group (Governance)
• Requirement B: Subscription (Billing)
• Requirement C: Resource Group (Lifecycle)

Think of the Azure Hierarchy as a two-way street: Money flows Up, Rules flow Down.

Visualizing the flow of Governance vs. Billing.

1. Management Group (The Umbrella):
Used for Governance. If you set a policy here (e.g., “No servers in Japan”), it automatically trickles down to every subscription underneath.

2. Subscription (The Bill):
Used for Billing. Costs from all your VMs and databases bubble up and stop here. This is where the invoice is generated.

3. Resource Group (The Container):
Used for Lifecycle Management. It groups resources that share the same life. If you delete the Resource Group, you delete everything inside it instantly.

• Statement 1: NO. Not all regions have Availability Zones. They are recommended but not universal.
• Statement 2: YES. This is the standard definition. A zone provides physical isolation via independent power/cooling.
• Statement 3: NO. Region Pairs are updated sequentially (one after the other) to prevent global failures.

The key to Azure reliability is isolation. Availability Zones isolate you from a datacenter failure within a region. Region Pairs isolate you from a total region failure. Updates are serialized (Region A, then Region B) to ensure that if an update causes a crash, it only affects one half of the pair.

Visualizing the layers of isolation: Zones vs. Region Pairs.

Azure compute services are distinguished by how responsibility is divided between the customer and Azure. As abstraction increases, Azure assumes responsibility for more layers of the execution environment, while the customer focuses primarily on application logic.

This diagram highlights how management responsibility shifts across virtual machines, containers, and serverless compute.

Azure networking services solve different problems. Connectivity is how traffic flows between resources. Name resolution is how resources find each other by name. DNS maps names to IP addresses, it does not create network connectivity.

Connectivity moves traffic. Name resolution maps names to IP addresses.

Same Azure service, different network exposure model based on the endpoint type.

When a workload runs on virtual machines, there are two ways to add capacity. You can increase resources on the same machine, or you can add more machines and distribute the workload. The deciding factor is whether the application can run across multiple servers.

Vertical scaling, scale up, increases CPU and memory on the existing virtual machine, typically by resizing it to a larger VM size. This is the right approach when the application must remain on a single server.

Horizontal scaling, scale out, adds more virtual machines and spreads traffic across them using load balancing or services like Virtual Machine Scale Sets. This only works when the application supports multiple instances.

Scale up increases resources on one VM. Scale out adds VMs and distributes the workload.

B. Resize the virtual machine to a more powerful SKU

A. Add another virtual machine and distribute traffic across both machines
This is horizontal scaling. It requires the application to run on multiple servers, which the scenario says is not supported.

C. Enable Azure Virtual Machine Scale Sets
Scale Sets are designed to deploy and manage multiple VM instances for scale out. They do not increase CPU or memory for a single existing VM.

D. Migrate the application to Azure App Service
This changes the hosting platform and can require redesign or refactoring. It does not directly satisfy the requirement to increase compute and memory on the existing virtual machine.

Compare Azure VM, App Service, and Functions by control, responsibility, and billing.