Domain 2: Describe Azure Architecture and Services

Microsoft Azure Fundamentals (AZ-900) — Domain 2: Describe Azure Architecture and Services

Exam Code: AZ-900  |  Level: Foundational
Domain Weight: 35–40%  |  Total Domains: 3  |  Passing Score: 700/1000

---

Table of Contents

1. Core Architectural Components
   • 1.1 Physical Infrastructure: Regions and Availability Zones
   • 1.2 Management Infrastructure: Resources, Groups, and Subscriptions
   • 1.3 Management Groups and Hierarchy
2. Azure Compute Services
   • 2.1 Azure Virtual Machines
   • 2.2 Azure Virtual Machine Scale Sets
   • 2.3 Azure App Service
   • 2.4 Azure Container Instances and Azure Kubernetes Service
   • 2.5 Azure Functions — Serverless Compute
   • 2.6 Azure Virtual Desktop
   • 2.7 Compute Service Comparison
3. Azure Networking Services
   • 3.1 Azure Virtual Network
   • 3.2 Azure VPN Gateway
   • 3.3 Azure ExpressRoute
   • 3.4 Azure DNS
   • 3.5 Azure Load Balancer and Application Gateway
   • 3.6 Azure Content Delivery Network
   • 3.7 Network Peering and Service Endpoints
4. Azure Storage Services
   • 4.1 Azure Storage Account Overview
   • 4.2 Azure Blob Storage
   • 4.3 Azure File Storage
   • 4.4 Azure Queue Storage and Azure Table Storage
   • 4.5 Azure Disk Storage
   • 4.6 Storage Access Tiers
   • 4.7 Storage Redundancy Options
   • 4.8 Azure Migrate and Azure Data Box
5. Azure Identity, Access, and Security
   • 5.1 Microsoft Entra ID (Azure Active Directory)
   • 5.2 Authentication Methods
   • 5.3 Azure Role-Based Access Control
   • 5.4 Zero Trust Security Model
   • 5.5 Defense in Depth
   • 5.6 Microsoft Defender for Cloud
6. Exam Tips & Quick Reference

---

1. Core Architectural Components

Azure's physical and logical infrastructure is organized in a hierarchy — from global datacenters down to individual resources. Understanding this hierarchy is critical: it determines how services are deployed, how availability is ensured, and how management, billing, and governance are applied.

1.1 Physical Infrastructure: Regions and Availability Zones

Regions

An Azure region is a geographical area containing one or more datacenters that are networked together with a low-latency network. When you deploy resources, you choose a region — this determines the physical location where your data and services live.

• Azure has 60+ regions globally (more than any other cloud provider)
• Most Azure services are region-specific — you must choose a region at deployment time
• Some services are global (e.g., Azure Active Directory, Azure Traffic Manager)

Key Concept: Region selection matters for three reasons: latency (place resources near users), data residency (legal requirements to keep data in a country), and disaster recovery (pair regions for failover).

Region Pairs

Every Azure region is paired with another region in the same geography, at least 300 miles apart. This is used for automatic geo-redundant replication.

Benefits of Region Pairs:

• If a major outage affects one region, services automatically fail over to the paired region
• Azure sequential updates — only one region in a pair is updated at a time, reducing risk
• Data replication between pairs for services like Azure Storage (GRS)

Exam Tip: Region pairs are predetermined by Microsoft — you cannot choose your own pair. Also, not all services automatically replicate to the paired region; you must configure geo-redundancy explicitly.

Sovereign Regions

Sovereign regions are isolated Azure instances designed for specific regulatory or governmental needs. They are physically and logically separated from the main Azure public cloud.

Availability Zones

An Availability Zone (AZ) is a physically separate datacenter within a single Azure region, each with independent power, cooling, and networking. Azure guarantees at least 3 Availability Zones in every AZ-enabled region.

Key Concept: Availability Zones protect against datacenter-level failures. If one AZ goes down (e.g., a power outage in that building), your application keeps running from another AZ in the same region.

Azure Region: East US
┌──────────────────────────────────────────────────┐
│  ┌─────────────┐  ┌─────────────┐  ┌───────────┐ │
│  │ Zone 1      │  │ Zone 2      │  │ Zone 3    │ │
│  │ Datacenter  │  │ Datacenter  │  │Datacenter │ │
│  │ [Power A]   │  │ [Power B]   │  │[Power C]  │ │
│  │ [Network A] │  │ [Network B] │  │[Network C]│ │
│  └─────────────┘  └─────────────┘  └───────────┘ │
│        Connected via high-speed fiber              │
└──────────────────────────────────────────────────┘

Zonal Services: Pinned to a specific zone (e.g., a VM in Zone 1).
Zone-Redundant Services: Automatically replicated across zones (e.g., Azure SQL with zone redundancy enabled).

Note: Not all Azure regions support Availability Zones. When AZs are available, they are the recommended approach for high-availability architectures.

---

1.2 Management Infrastructure: Resources, Groups, and Subscriptions

Azure uses a four-level management hierarchy to organize resources. Each level inherits policies and access controls from the level above.

Management Groups
    │
    ▼
Subscriptions
    │
    ▼
Resource Groups
    │
    ▼
Resources (VMs, Storage, DBs, etc.)

Resources

A resource is the basic building block of Azure — any manageable item you create and use. Examples: a virtual machine, a storage account, a SQL database, a virtual network.

• Every resource exists in exactly one resource group
• Resources are billed individually
• Each resource has a unique Azure Resource ID (ARM ID)

Resource Groups

A resource group is a logical container that holds related Azure resources for a solution. It is a fundamental organizational unit in Azure.

Key Rules of Resource Groups:

• A resource can only exist in one resource group at a time
• Resources can be moved between resource groups (with some limitations)
• Deleting a resource group deletes all resources inside it
• Resources in a resource group can be in different regions — the resource group itself has a location (for metadata), but it doesn't constrain where resources are deployed
• Tags, access policies (RBAC), and locks applied to a resource group are inherited by its resources

Exam Tip: Resource groups are not hierarchical — you cannot nest a resource group inside another resource group. For hierarchy, use Management Groups.

Best practice: Group resources by lifecycle. Resources that are deployed, managed, and deleted together should be in the same resource group (e.g., all resources for a web app: VM + database + storage account + network).

Subscriptions

An Azure subscription is a billing unit and a logical boundary for Azure resources. It links to an Azure account and defines the scope for billing and access control.

Every subscription has:

• A unique Subscription ID
• Billing ownership (who pays the Azure bills)
• Resource and service limits (quotas)
• Its own set of resource groups

An organization can have multiple subscriptions for different purposes:

Key Concept: Subscriptions create a billing boundary (each subscription generates its own invoice) and an access management boundary (RBAC policies can be scoped at the subscription level).

---

1.3 Management Groups and Hierarchy

Management Groups are containers that organize subscriptions into a hierarchy above the subscription level. They allow consistent governance policies and access controls to be applied across multiple subscriptions simultaneously.

Key Facts:

• Management groups can be nested (up to 6 levels deep, not counting the root and subscription levels)
• All subscriptions within a management group inherit the policies and RBAC assignments of that group
• Every tenant has a single Root Management Group at the top
• Management groups can contain subscriptions or other management groups (but not resources directly)

Root Management Group (Tenant)
├── IT Management Group
│   ├── Subscription: IT-Production
│   └── Subscription: IT-Dev
├── Business Units Management Group
│   ├── Finance MG
│   │   ├── Subscription: Finance-APAC
│   │   └── Subscription: Finance-EMEA
│   └── HR Management Group
│       └── Subscription: HR-Global
└── Sandbox Management Group
    └── Subscription: Sandbox-Dev

Exam Tip: If a question asks how to apply a policy to all subscriptions in an organization simultaneously, the answer is Management Groups — not resource groups or individual subscriptions.

---

2. Azure Compute Services

Azure offers multiple compute options ranging from full virtual machines (maximum control) to serverless functions (zero infrastructure management). Choosing the right compute service is one of the most common exam scenario patterns.

2.1 Azure Virtual Machines

Azure Virtual Machines (VMs) are IaaS offerings that provide virtualized computing. You choose the operating system, configure the environment, install software, and manage everything except the underlying physical hardware.

When to use Azure VMs:

• Full control over the OS is required (custom configurations, legacy software)
• Running applications that require a specific OS version
• Extending an on-premises datacenter to the cloud (lift-and-shift)
• Custom software environments not available in PaaS offerings

VM Series and Use Cases:

Key Concept: A VM in Azure is billed even when stopped (in a "Stopped" state from within the OS). You must Deallocate the VM through Azure to stop billing for compute. This is a common operational gotcha.

VM Availability Options:

• Availability Sets: Distribute VMs across Fault Domains (separate physical racks) and Update Domains (staggered maintenance windows) within one datacenter. Protects against hardware failure and planned maintenance — not against datacenter failure.
• Availability Zones: Distribute VMs across physically separate datacenters within a region. Protects against datacenter failure.
• Region Pairs: Replicate VMs across regions for full regional disaster recovery.

---

2.2 Azure Virtual Machine Scale Sets

Azure Virtual Machine Scale Sets (VMSS) allow you to create and manage a group of identical, load-balanced VMs that automatically scale based on demand or a schedule.

• All VMs in a scale set are identical (same image, size, configuration)
• Azure can automatically increase or decrease the number of VM instances
• Integrated with Azure Load Balancer and Application Gateway for traffic distribution
• Supports up to 1,000 VM instances per scale set (100 for custom images)

Exam Tip: When a scenario describes "automatically increasing compute capacity during peak hours and reducing it during off-peak hours," the answer is VM Scale Sets (for VM-based workloads).

---

2.3 Azure App Service

Azure App Service is a fully managed PaaS for hosting web applications, REST APIs, and mobile back-ends. You deploy your code; Azure manages the infrastructure, OS, runtime, patching, and scaling.

Supported languages and runtimes:

• .NET / .NET Core
• Node.js
• Python
• Java
• PHP
• Ruby
• Custom containers (Docker)

App Service Plan: Defines the compute resources (region, VM size, OS, number of instances) that your apps run on. Multiple apps can share one App Service Plan.

Exam Tip: App Service is the go-to answer for "host a web app without managing servers." It's PaaS, so OS patching, infrastructure scaling, and load balancing are handled by Azure.

---

2.4 Azure Container Instances and Azure Kubernetes Service

Containers vs Virtual Machines

Containers package an application and its dependencies into a single, lightweight unit that can run consistently across any environment. Unlike VMs, containers share the host OS kernel — making them faster to start and more resource-efficient.

Virtual Machine:
┌─────────────────────────────┐
│  App A  │  App B  │  App C  │
├─────────┤─────────┤─────────┤
│  OS A   │  OS B   │  OS C   │  ◄── Each VM has its own OS
├─────────┴─────────┴─────────┤
│        Hypervisor           │
├─────────────────────────────┤
│      Physical Hardware      │
└─────────────────────────────┘

Containers:
┌─────────────────────────────┐
│ Container A │ Container B   │
│  (App + Libs)│ (App + Libs) │
├─────────────┴───────────────┤
│     Container Runtime       │
├─────────────────────────────┤
│  Host OS (shared kernel)    │
├─────────────────────────────┤
│     Physical Hardware       │
└─────────────────────────────┘

Azure Container Instances (ACI)

Azure Container Instances is the simplest way to run containers in Azure — no VM management, no cluster setup. You submit a container image and ACI runs it, billing you per second of actual use.

• Fastest way to deploy a container in Azure
• No orchestration — suitable for simple, isolated containers or burst scenarios
• Billed per CPU and memory per second
• Supports Linux and Windows containers

Azure Kubernetes Service (AKS)

Azure Kubernetes Service is a managed Kubernetes cluster on Azure. Kubernetes orchestrates containers across multiple nodes — handling deployment, scaling, load balancing, and self-healing.

• Microsoft manages the control plane (free of charge)
• You manage the worker nodes (billed as VMs)
• Best for complex, microservices-based applications at scale
• Integrates with Azure Container Registry (ACR) for private image storage

Exam Tip: ACI = simple, fast, no management, single containers. AKS = orchestration, scaling, microservices, complex containerized applications. The exam tests when each is appropriate.

---

2.5 Azure Functions — Serverless Compute

Azure Functions is a serverless compute service that lets you run small pieces of code ("functions") in response to events — without provisioning or managing any infrastructure.

Key Concept: Serverless does NOT mean "no servers." It means you don't see or manage the servers. The infrastructure scales automatically, and you pay only for the exact execution time and resources consumed.

How Azure Functions works:

Event Trigger
  (HTTP request, timer, message in queue, blob upload, etc.)
      │
      ▼
Azure Functions Runtime
  (allocates compute on demand)
      │
      ▼
Your Code Executes
  (milliseconds to a few minutes)
      │
      ▼
Billing: charged per execution + execution time
  (first 1 million executions per month FREE)

Common Azure Functions Triggers:

Hosting Plans:

---

2.6 Azure Virtual Desktop

Azure Virtual Desktop (AVD) is a cloud-based desktop and application virtualization service. It lets users access a full Windows desktop experience from any device, anywhere.

• Runs on Azure VMs; accessed via Remote Desktop client or browser
• Supports Windows 10/11 multi-session (multiple users on one VM — cost efficient)
• Integrates with Microsoft 365 and Microsoft Entra ID
• Full data stays in Azure — no data on the endpoint device
• Common use case: remote work, BYOD (Bring Your Own Device), call centers

---

2.7 Compute Service Comparison

---

3. Azure Networking Services

Azure networking connects your Azure resources to each other, to on-premises networks, and to the internet. Networking is the backbone of every cloud architecture.

3.1 Azure Virtual Network

An Azure Virtual Network (VNet) is a logically isolated network in Azure. It enables Azure resources to securely communicate with each other, the internet, and on-premises networks.

• Think of a VNet as your private network in the cloud (analogous to a LAN)
• VNets are scoped to a single region — you cannot span a single VNet across regions
• VNets are divided into subnets for network segmentation

Key VNet Capabilities:

Key Concept: By default, resources in a VNet can communicate with each other, but resources in different VNets cannot communicate unless you configure VNet Peering or a VPN.

---

3.2 Azure VPN Gateway

Azure VPN Gateway creates an encrypted tunnel between an Azure VNet and an on-premises network (or another Azure VNet) over the public internet using IPsec/IKE protocols.

Two main connection types:

Site-to-Site VPN

Connects an entire on-premises network to an Azure VNet. Requires a compatible VPN device (hardware or software) on-premises. The tunnel is always active.

Point-to-Site VPN

Connects individual client devices to an Azure VNet. No on-premises VPN hardware required. Used for remote workers needing secure access to Azure resources.

On-Premises Network ◄──── IPsec Tunnel ────► Azure VPN Gateway ──► Azure VNet
   (Office LAN)           (Over Internet)                           (Cloud Resources)

Exam Tip: VPN Gateway = encrypted tunnel over the internet. It's secure but shares the public internet — meaning bandwidth is variable and latency can spike. For dedicated, private connectivity, use ExpressRoute.

---

3.3 Azure ExpressRoute

Azure ExpressRoute provides a dedicated private connection from an on-premises network to Microsoft's cloud infrastructure — bypassing the public internet entirely. The connection is provisioned through a connectivity provider (e.g., AT&T, Equinix).

Key Differences: VPN Gateway vs ExpressRoute:

Exam Tip: When a scenario mentions "consistent latency," "high bandwidth," "private connection," or "doesn't use the public internet," the answer is ExpressRoute — not VPN Gateway.

---

3.4 Azure DNS

Azure DNS is a hosting service for DNS domains that uses Azure infrastructure. It resolves domain names to IP addresses and integrates natively with other Azure services.

• Hosts DNS zones and manages DNS records (A, AAAA, CNAME, MX, TXT, etc.)
• Uses Anycast routing — queries routed to the nearest DNS server globally
• Private DNS Zones: Resolve domain names within a VNet without exposing them publicly
• Azure-provided DNS: Every VNet gets automatic DNS resolution for Azure resources (e.g., myvm.internal.cloudapp.net)

Note: Azure DNS cannot register domain names — you purchase domain names through a registrar (e.g., GoDaddy) and then host them on Azure DNS.

---

3.5 Azure Load Balancer and Application Gateway

Azure Load Balancer

Azure Load Balancer distributes inbound network traffic across multiple backend resources (VMs) to ensure high availability and reliability. It operates at Layer 4 (Transport layer — TCP/UDP).

• Supports Public Load Balancer (internet-facing) and Internal Load Balancer (private traffic within a VNet)
• Health probes detect unhealthy instances and stop sending traffic to them
• No understanding of HTTP — just distributes TCP/UDP flows

Azure Application Gateway

Azure Application Gateway is a web traffic load balancer at Layer 7 (Application layer — HTTP/HTTPS). It understands web traffic and can make routing decisions based on URLs, host headers, and more.

Exam Tip: "Route traffic based on the URL path" or "need a Web Application Firewall" → Application Gateway. "Simple load balancing of TCP traffic" → Load Balancer.

---

3.6 Azure Content Delivery Network

Azure Content Delivery Network (CDN) is a distributed network of servers that caches and delivers static content (images, videos, CSS, JavaScript) to users from the nearest edge location — reducing latency and improving performance for global users.

User in Tokyo ──► Nearest CDN Edge Node (Tokyo) ──► Cache HIT → delivers content
                                                   ──► Cache MISS → fetches from Origin → caches
Origin (Azure Storage or Web App in East US)

• Dramatically reduces load on origin servers
• Content is served from hundreds of Points of Presence (PoPs) worldwide
• Supports HTTPS, custom domains, and compression
• Use case: websites with global audiences, media streaming, large file distribution

---

3.7 Network Peering and Service Endpoints

VNet Peering

VNet Peering connects two Azure VNets so resources in both VNets can communicate using private IP addresses — without routing traffic through the public internet or a VPN gateway.

• Regional VNet Peering: Connects VNets in the same region
• Global VNet Peering: Connects VNets across different regions
• Traffic flows over Microsoft's backbone network (low latency, high bandwidth)
• Not transitive — if VNet A peers with VNet B, and VNet B peers with VNet C, VNet A and VNet C cannot communicate unless directly peered

Service Endpoints

Service Endpoints allow you to extend your VNet's private address space to reach Azure PaaS services (like Azure Storage or Azure SQL) directly over the Microsoft backbone — without the traffic leaving the Azure network.

Note: Service Endpoints give PaaS services awareness of your VNet's traffic, but the PaaS service still has a public endpoint. Private Endpoints fully bring the service into your VNet with a private IP — providing stronger isolation.

---

4. Azure Storage Services

Azure Storage is a massively scalable, durable, and secure cloud storage platform. It is the foundation of many Azure services and supports structured, unstructured, and binary data.

4.1 Azure Storage Account Overview

An Azure Storage Account is the top-level resource that contains all Azure Storage data objects: blobs, files, queues, and tables. It provides a unique namespace accessible over HTTP/HTTPS from anywhere in the world.

Every storage account must have:

• A globally unique name (becomes part of the endpoint URL)
• A location (Azure region)
• A performance tier (Standard or Premium)
• A redundancy type (LRS, ZRS, GRS, GZRS)

Storage account types:

---

4.2 Azure Blob Storage

Azure Blob Storage is optimized for storing massive amounts of unstructured data — data that doesn't conform to a particular data model or definition (text files, images, videos, backups, log files, archives).

"Blob" stands for Binary Large Object.

Blob types:

Exam Tip: Block Blobs are the most commonly used type. Page Blobs are specifically used for VM disk (VHD) storage — this distinction is frequently tested.

Blob Storage endpoints follow this format:

https://<storage-account-name>.blob.core.windows.net/<container>/<blob-name>

---

4.3 Azure File Storage

Azure Files offers fully managed, cloud-based file shares accessible via the SMB (Server Message Block) protocol — the same protocol used by Windows file shares — and the NFS (Network File System) protocol.

• Can be mounted simultaneously on Windows, Linux, and macOS
• Lift-and-shift: replace or supplement on-premises file servers
• Supports Azure File Sync — keeps Windows Server file servers in sync with Azure Files, with cloud-based caching
• Accessible from anywhere with credentials (no VPN required for SMB 3.0)

Exam Tip: Azure Files is the answer when a scenario mentions "replace on-premises file share," "shared network drive," "SMB protocol," or "mount on multiple machines simultaneously."

---

4.4 Azure Queue Storage and Azure Table Storage

Azure Queue Storage

Azure Queue Storage stores large numbers of messages that can be accessed from anywhere via authenticated HTTP/HTTPS calls. A single queue can hold millions of messages, each up to 64 KB in size.

• Used for asynchronous communication between application components
• Enables decoupling of producers (who create work) from consumers (who process work)
• Messages persist until a consumer reads and deletes them
• Common in microservices and event-driven architectures

Azure Table Storage

Azure Table Storage is a NoSQL key-attribute store that stores structured, non-relational data. It stores data as a collection of entities (rows) with properties (columns).

• Schema-less — entities can have different sets of properties
• Designed for fast reads/writes on large volumes of structured data
• Cheaper than Azure SQL Database for simple key-value lookups
• Use case: storing user preferences, device metadata, telemetry, lookup tables

Note: Azure Cosmos DB for Table is the premium, globally distributed successor to Azure Table Storage — offering multi-region writes and lower latency. For simple, cost-effective scenarios, Azure Table Storage is sufficient.

---

4.5 Azure Disk Storage

Azure Managed Disks are block-level storage volumes managed by Azure that are used with Azure VMs. "Managed" means Azure handles replication, availability, and lifecycle — you simply attach the disk to a VM.

Key Point: Ultra Disk and Premium SSD v2 allow configuring IOPS and throughput independently — giving fine-grained performance tuning not available in other disk types.

---

4.6 Storage Access Tiers

Azure Blob Storage supports access tiers that allow you to balance storage cost against retrieval cost based on how frequently data is accessed. Tiers apply at the blob level or as the account default.

Exam Tip: Archive tier data is offline — it must be rehydrated (moved to Hot or Cool tier) before it can be accessed. Rehydration can take up to 15 hours. This is the key difference between Archive and the other tiers.

Lifecycle Management: Azure Storage Lifecycle Management policies can automatically move blobs between tiers or delete them based on age or last-access time — fully automated cost optimization.

---

4.7 Storage Redundancy Options

Azure Storage always stores multiple copies of your data to protect it from hardware failures. The redundancy option you choose determines where those copies are stored.

Exam Tip: LRS is the cheapest option and the default. GRS replicates to a paired region automatically. The "RA-" prefix means you can read from the secondary region even without a failover — useful for globally distributed read scenarios.

---

4.8 Azure Migrate and Azure Data Box

Azure Migrate

Azure Migrate is a centralized hub for discovering, assessing, and migrating on-premises servers, databases, and applications to Azure.

• Discovery & Assessment: Discovers on-premises VMware, Hyper-V, and physical servers; analyzes workloads and recommends Azure VM sizes and costs
• Server Migration: Replicates and migrates VMs to Azure (with near-zero downtime)
• Database Migration: Migrates SQL Server, Oracle, MySQL databases to Azure SQL services
• Integrates with third-party ISV tools (Carbonite, Zerto, etc.)

Azure Data Box

Azure Data Box is a physical device that Microsoft ships to you for offline bulk data transfer when the internet connection is too slow or unreliable for large datasets.

• Data Box holds up to 80 TB of usable storage
• You copy data onto it, ship it back to Microsoft, and they upload it to your Azure storage account
• Ideal for initial migration of large datasets (10+ TB)

Data Box family:

Exam Tip: When a scenario says "company has 50 TB of data on-premises and their internet connection would take months to upload," the answer is Azure Data Box — not Azure Migrate (which works over the internet).

---

5. Azure Identity, Access, and Security

Identity is the new perimeter. In a cloud world where users access resources from any device and location, verifying identity is more important than managing network boundaries. Azure provides a comprehensive identity and security platform.

5.1 Microsoft Entra ID (Azure Active Directory)

Microsoft Entra ID (formerly Azure Active Directory / Azure AD) is Microsoft's cloud-based identity and access management (IAM) service. It serves as the central identity platform for Azure, Microsoft 365, and thousands of third-party applications.

Key Concept: Microsoft Entra ID is not the same as Windows Active Directory (AD DS). Windows AD manages on-premises computers, printers, and network resources using LDAP and Kerberos. Entra ID is cloud-native and uses open standards (OAuth, OIDC, SAML) designed for web and cloud applications.

What Entra ID provides:

Entra ID Tenants:

A tenant is a dedicated, trusted instance of Entra ID that an organization receives when it signs up for a Microsoft cloud service. Each organization has one tenant. Your tenant contains your users, groups, and app registrations.

Exam Tip: Azure AD Connect (now Microsoft Entra Connect) synchronizes on-premises Active Directory with Entra ID — enabling Hybrid Identity where users use the same credentials on-premises and in the cloud.

---

5.2 Authentication Methods

Authentication is the process of proving you are who you claim to be. Azure supports multiple methods:

Single Sign-On (SSO)

SSO allows users to sign in once and access multiple applications without re-entering credentials. The user authenticates to Entra ID, which then issues tokens to other connected apps.

• Reduces password fatigue and reuse
• Single point to revoke access (deactivate one account → access to all apps revoked)
• Used for Microsoft 365, Azure portal, and thousands of integrated SaaS apps

Multi-Factor Authentication (MFA)

MFA requires two or more verification factors to authenticate:

1. Something you know — password or PIN
2. Something you have — authenticator app, hardware token, SMS code
3. Something you are — fingerprint, face recognition (biometrics)

Key Concept: Passwords alone are insufficient — they can be stolen, phished, or guessed. MFA adds a layer that requires physical possession of a device, making account compromise dramatically harder even if the password is exposed.

Passwordless Authentication

Microsoft Entra ID supports authentication without passwords using:

• Windows Hello for Business — biometric or PIN tied to a specific device
• Microsoft Authenticator App — approve sign-in from a phone notification
• FIDO2 Security Keys — physical hardware keys (YubiKey, etc.)

Conditional Access

Conditional Access is a policy engine in Entra ID that evaluates signals to make access decisions before granting or blocking access to a resource.

Signal Inputs:
  User/Group | Location (IP/Country) | Device state | Application | Risk level
        │
        ▼
  Conditional Access Policy Engine
        │
        ▼
  Decision:
  ✅ Grant access
  ✅ Grant access with MFA requirement
  ✅ Grant access if device is compliant
  ❌ Block access

Common Conditional Access policies:

• Require MFA for all admin roles
• Block access from unknown locations or countries
• Allow access only from compliant (Intune-managed) devices
• Block legacy authentication protocols

---

5.3 Azure Role-Based Access Control

Azure Role-Based Access Control (RBAC) is the authorization system used to control who has access to Azure resources, what they can do with them, and what scope they have access to.

Key Concept: RBAC answers: Who (security principal) can do what (role) on which resources (scope)?

Three key components of Azure RBAC:

Built-in roles:

Principle of Least Privilege: Assign users and services only the minimum permissions they need to do their job. Never assign Owner when Contributor or Reader would suffice.

Scope Hierarchy (permissions inherit downward):
Management Group
  └── Subscription (role assigned here applies to all RGs and resources below)
        └── Resource Group
              └── Resource (most granular scope)

Exam Tip: RBAC roles are additive — if you have Contributor at the subscription level and Reader at the resource group level, you effectively have Contributor. There is no "deny" in basic RBAC (Azure Policy can deny). Owner is the only built-in role that can assign roles to others.

---

5.4 Zero Trust Security Model

Zero Trust is a security model that eliminates the assumption that anything inside the corporate network is trustworthy. It treats every request as if it comes from an untrusted network, regardless of origin.

Three Zero Trust Principles:

1. Verify explicitly — Always authenticate and authorize based on all available data points (identity, location, device, service, workload, data classification, anomalies)
2. Use least privilege access — Limit user access with just-in-time and just-enough-access, risk-based adaptive policies, and data protection
3. Assume breach — Minimize blast radius, segment access, verify end-to-end encryption, use analytics to get visibility and drive threat detection

Traditional perimeter security vs Zero Trust:

Key Concept: Zero Trust is a philosophy and architecture approach — not a single product. Microsoft implements Zero Trust through Entra ID, Conditional Access, Defender for Cloud, Microsoft Sentinel, and Azure networking controls.

---

5.5 Defense in Depth

Defense in Depth is a security strategy that uses multiple layers of security controls, so that if one layer is breached, additional layers continue to protect the system.

Defense in Depth Layers (Outside → Inside):

┌─────────────────────────────────────┐
│  Physical Security                  │  Data center access, biometrics
│  ┌───────────────────────────────┐  │
│  │  Identity & Access            │  │  Entra ID, MFA, Conditional Access
│  │  ┌─────────────────────────┐  │  │
│  │  │  Perimeter              │  │  │  DDoS protection, Azure Firewall
│  │  │  ┌───────────────────┐  │  │  │
│  │  │  │  Network          │  │  │  │  NSGs, VNet, subnets
│  │  │  │  ┌─────────────┐  │  │  │  │
│  │  │  │  │  Compute    │  │  │  │  │  Endpoint protection, VM patches
│  │  │  │  │  ┌───────┐  │  │  │  │  │
│  │  │  │  │  │ App   │  │  │  │  │  │  Secure coding, WAF
│  │  │  │  │  │ ┌───┐ │  │  │  │  │  │
│  │  │  │  │  │ │Data│ │  │  │  │  │  │  Encryption, access control
│  │  │  │  │  │ └───┘ │  │  │  │  │  │

Each layer is an independent line of defense. An attacker who compromises the network perimeter still faces identity verification, application-level controls, and data encryption.

---

5.6 Microsoft Defender for Cloud

Microsoft Defender for Cloud is a cloud security posture management (CSPM) and cloud workload protection platform (CWPP) that monitors your Azure resources and provides security recommendations and threat protection.

Two main pillars:

1. Cloud Security Posture Management (CSPM): Continuously assesses your Azure environment and provides a Secure Score — a percentage representing how well you follow security best practices. Higher score = better security posture.

2. Cloud Workload Protection (CWP): Provides advanced threat protection for specific Azure services (VMs, SQL databases, Kubernetes clusters, App Service, Storage accounts, etc.).

Key Concept: The Secure Score in Defender for Cloud is a measurable, actionable metric. When the score goes up, your security posture improves. Exam questions may reference this as the way to measure and improve security across Azure resources.

Defender for Cloud capabilities:

---

Exam Tips & Quick Reference

Scenario-to-Answer Mapping

---

Common Traps

• Azure AD vs Windows AD: Azure AD (Entra ID) is a cloud identity service; Windows Active Directory Domain Services (AD DS) is an on-premises directory. They are different products. Entra ID uses OAuth/OIDC; AD DS uses LDAP/Kerberos. Azure AD Connect bridges the two.
• App Service is not serverless: It's PaaS — the servers exist, Microsoft manages them. Azure Functions is the serverless option. App Service runs persistently; Functions run only when triggered.
• Availability Sets vs Availability Zones: Availability Sets protect against hardware rack and update failures within one datacenter. Availability Zones protect against entire datacenter failures within one region. Zones provide stronger protection.
• VNet Peering is not transitive: A → B peered, B → C peered does NOT mean A can reach C. You must peer A → C explicitly.
• Blob Archive tier is offline: You cannot read Archive-tier blobs directly. They must be rehydrated first, which takes up to 15 hours. Candidates often forget this and choose Archive when the scenario requires immediate access.
• RBAC Contributor cannot assign roles: Only the Owner and User Access Administrator built-in roles can assign RBAC roles to others. Contributor has full resource control but no access management.
• LRS is NOT zone-redundant: LRS stores 3 copies in one datacenter — rack failure might affect all 3. For datacenter-level protection, use ZRS or higher.
• Azure Data Box vs Azure Migrate: Data Box is for offline physical data transfer. Azure Migrate is for online server assessment and migration. If internet bandwidth is the bottleneck → Data Box. If you need to assess and plan migration → Azure Migrate.

---

Key Terms — Domain 2

---

End of Domain 2. Continue to [Domain 3: Describe Azure Management and Governance] →