Azure AD (Entra ID) vs Azure RBAC

These are two separate permission systems and mixing them up is the classic exam trap.

• Microsoft Entra ID (formerly Azure AD) roles control access to directory-level resources: users, groups, licences, domains, app registrations.
• Azure RBAC controls access to Azure resources: VMs, storage accounts, resource groups, subscriptions.
• A Global Administrator does not automatically get access to manage Azure resources - they must elevate access explicitly via 'Access management for Azure resources' in the Properties blade of Entra ID.

RBAC structure

• Scope hierarchy, broadest to narrowest: Management Group > Subscription > Resource Group > Resource.
• Permissions are inherited downward - a role assigned at a Management Group flows to every subscription and resource beneath it.
• A role assignment = security principal (user/group/service principal/managed identity) + role definition + scope.
• Built-in roles to know: Owner (full access plus can assign roles), Contributor (full access, cannot assign roles), Reader (view only), User Access Administrator (manage role assignments only).
• Deny assignments always override Allow - Azure Blueprints/Policy can create these and they cannot be changed by Contributor.
• Multiple role assignments are additive - the effective permission is the union.

Custom roles

• Defined as JSON with Actions, NotActions, DataActions, NotDataActions, and AssignableScopes.
• Can be created via Azure CLI, PowerShell, or the portal; a subscription can hold up to 5,000 custom roles (Entra ID custom roles are capped separately, around 100-ish per tenant depending on licence).

Management groups and subscriptions

• Up to six levels of management groups depth (not counting the Root or subscription level).
• A management group tree can have one Root management group only, and all subscriptions in a tenant funnel into it.
• Azure Policy assigned at a management group cascades to all child subscriptions and resource groups - use it to enforce tagging, allowed regions, or allowed SKUs.

Users, groups and licensing

• Two group types: Security groups (used for RBAC/resource access) and Microsoft 365 groups (collaboration, mailbox, SharePoint).
• Membership type can be Assigned (manual) or Dynamic (rule-based on user/device attributes) - dynamic groups require Entra ID P1 licensing.
• Guest users (B2B) are invited via email and get a #EXT# suffix in their UPN; they can be assigned RBAC roles and app access just like members.
• Self-service password reset (SSPR) needs Entra ID P1 for cloud-only users doing combined registration; basic SSPR works on Free tier for cloud users only in limited scenarios - know that P1/P2 unlocks the full feature set including Conditional Access.

Common mistakes

• Forgetting that RBAC and Entra ID roles are entirely separate scopes of control.
• Assuming Contributor can change access - it cannot; only Owner or User Access Administrator can.
• Applying a Deny assignment expectation to a normal role - Deny only comes from Blueprints/Policy, not standard RBAC.
• Forgetting dynamic groups need a paid licence tier.

Storage accounts: the basics

An Azure storage account is the top-level container for blobs, files, queues, tables and disks. Name must be globally unique, 3-24 characters, lowercase letters and numbers only.

Performance tiers:

• Standard: HDD-based, general purpose, cheapest.
• Premium: SSD-based, low latency, used for VM disks, block blobs or file shares needing high IOPS.

Redundancy (replication) options:

• LRS (Locally Redundant Storage): 3 copies in one datacentre, cheapest, no protection against datacentre failure.
• ZRS (Zone Redundant Storage): 3 copies across availability zones in one region.
• GRS (Geo-Redundant Storage): LRS copy plus async copy to a paired region (6 copies total, secondary not readable by default).
• RA-GRS: same as GRS but the secondary region is readable.
• GZRS / RA-GZRS: combines ZRS in primary region with geo-replication.

Access tiers for blob storage

Used to balance storage cost against access cost:

• Hot: frequent access, higher storage cost, lowest access cost.
• Cool: infrequent access (30+ days), lower storage cost, higher access cost, minimum 30-day retention.
• Cold: rarely accessed (90+ days), even lower storage cost, minimum 90-day retention.
• Archive: rarely accessed, cheapest storage, but offline — rehydration takes hours (standard priority up to 15 hours, high priority faster), minimum 180-day retention.

Lifecycle management policies automate moving blobs between tiers or deleting them based on age rules — a favourite exam scenario is cost optimisation using these rules.

Security essentials

• Shared Key (account key): full access, rotate regularly, avoid where possible.
• Shared Access Signatures (SAS): time-limited, scoped tokens (account SAS, service SAS, or user delegation SAS backed by Azure AD — most secure).
• Storage Firewall and Virtual Networks: restrict access to selected networks; 'Allow trusted Microsoft services' bypasses the firewall for select services.
• Encryption at rest is enabled by default (Microsoft-managed keys); customer-managed keys via Key Vault are optional.
• Secure transfer required (HTTPS only) should stay enabled.

Common mistakes to avoid

• Confusing GRS (not readable) with RA-GRS (readable secondary) — a classic exam trap.
• Forgetting that changing redundancy from LRS to GRS/ZRS can incur a one-off data transfer cost and requires the account to be unlocked/re-configured.
• Applying an Archive tier and expecting instant reads — it must be rehydrated first.
• Thinking Azure Files only supports SMB — it also supports NFS on Premium file shares (Linux-friendly).
• Forgetting Azure File Sync caches files locally on a Windows Server via cloud tiering, while still keeping the full set in Azure Files.

AzCopy and Storage Explorer

AzCopy is the command-line tool for high-performance bulk copy/move/sync of blobs and files; Storage Explorer gives a GUI. Both support async copy jobs between storage accounts, including cross-region.

VM sizing and availability

Pick a VM series based on workload: B-series is burstable/cheap for dev-test, D-series is general purpose, E-series is memory-optimised, F-series is compute-optimised.

Use Availability Sets for rack-level fault tolerance within one datacentre (2-3 fault domains, up to 20 update domains).

Use Availability Zones for datacentre-level resilience across a region (minimum 3 physical zones, each with independent power/cooling/networking).

A VM Scale Set (VMSS) automatically adds or removes identical VM instances based on demand or a schedule, and can span zones.

Disks and images

Managed disks come in four tiers: Ultra Disk, Premium SSD, Standard SSD, Standard HDD - Ultra and Premium need a compatible VM size (usually the 's' in the size name, eg Dsv5).

OS disks default to a 30-second write cache; data disks default to none for Premium SSD unless changed.

A Shared Image Gallery lets you version and replicate custom images across regions and subscriptions - better than plain managed images for scale.

Generalise a VM with sysprep (Windows) or waagent -deprovision (Linux) before capturing an image.

Common exam traps

Resizing a VM may be blocked if the target size isn't available on the current hardware cluster - you may need to deallocate first.

Moving a VM between Availability Sets is NOT possible after creation - you must delete and recreate it (or use Azure Migrate).

Update Domains are not evenly guaranteed - Azure decides placement; you just get the fault-tolerance benefit.

Containers: ACI vs AKS vs Web App for Containers

Azure Container Instances (ACI) is the fastest way to run a single container with no orchestration, billed per second - ideal for burst or batch jobs.

Azure Kubernetes Service (AKS) is the managed Kubernetes control plane - Microsoft manages the control plane free of charge, you pay only for the worker nodes.

AKS supports cluster autoscaler (nodes) and Horizontal Pod Autoscaler (pods) separately - know the difference.

Web App for Containers (App Service) runs a single container behind App Service's PaaS features (custom domains, easy auth, deployment slots).

Container instances can be placed in a virtual network for private connectivity, but only in a dedicated (delegated) subnet.

ACR (Azure Container Registry)

ACR has three tiers: Basic, Standard, Premium - only Premium supports geo-replication and private endpoints.

Use az acr build for cloud-based image builds without needing local Docker.

Enable admin user only for testing; production should use managed identity or service principal auth against ACR.

Common mistakes

Forgetting that stopping (not deallocating) a VM in the portal still bills compute charges - always use 'Stop (deallocated)' or the CLI az vm deallocate.

Assuming AKS control plane costs money on the Free tier - it doesn't, only nodes and the optional paid SLA tier do.

Confusing Availability Sets (single datacentre) with Availability Zones (multiple datacentres) - a very common AZ-104 distractor.

Virtual Networks (VNets) and subnets

A VNet is your private network in Azure, scoped to one region and one subscription. It's divided into subnets, and every subnet must sit inside the VNet's address space with no overlap between subnets.

• Azure reserves 5 IP addresses in every subnet: network address, default gateway, two for Azure DNS mapping, and the broadcast address. So a /29 (8 addresses) leaves only 3 usable.
• Smallest subnet allowed is /29, largest VNet address space is /8 (RFC1918 or public, but public ranges owned by others can't be used).
• VNets can't be resized smaller than their existing subnets, and you can't shrink a VNet if it would drop below an existing subnet's range.

Peering

VNet peering connects two VNets so resources talk over the Microsoft backbone using private IPs - no public internet, no VPN gateway needed.

• Peering is non-transitive: if A peers with B, and B peers with C, A cannot reach C automatically.
• Global peering connects VNets across regions; local peering is same-region.
• Peered VNets must NOT have overlapping address spaces.
• Gateway transit lets a peered VNet use the other's VPN/ExpressRoute gateway instead of deploying its own.

Network Security Groups (NSGs)

NSGs filter traffic by 5-tuple rules (source, source port, destination, destination port, protocol) and apply at the subnet or NIC level.

• Rules have priority 100-4096; lower number = higher priority, and the first matching rule wins - no more evaluation after that.
• Default rules (priority 65000+) allow VNet-to-VNet traffic, allow Azure Load Balancer traffic, and deny all other inbound.
• Default rules can't be deleted but can be overridden by higher-priority custom rules.
• When both a subnet NSG and a NIC NSG apply, BOTH must allow the traffic for it to pass (inbound: subnet then NIC; outbound: NIC then subnet).

Routing

Azure creates System Routes automatically (VNet local, on-premises via gateway, 0.0.0.0/0 to internet). User-Defined Routes (UDRs) override these via a Route Table attached to a subnet, commonly used to force traffic through a Network Virtual Appliance (NVA) or firewall.

Private endpoints vs Service endpoints

• A Service Endpoint extends the VNet identity to a PaaS service over the Azure backbone but the PaaS resource keeps a public IP.
• A Private Endpoint gives the PaaS resource a private IP inside your VNet (via Private Link) - this is the more secure, exam-favoured answer for locking down storage/SQL/etc.

Common mistakes

• Forgetting NSG rules evaluate lowest-priority-number-first and stop at the first match.
• Assuming peering is transitive - it isn't, you'd need a hub-and-spoke with the hub relaying (or mesh peering).
• Trying to peer VNets with overlapping CIDR ranges - this always fails.
• Confusing Service Endpoint (still public IP) with Private Endpoint (private IP, uses Private Link).

Monitor & maintain Azure resources

This topic covers Azure Monitor, Log Analytics, alerts, Network Watcher and backup/recovery basics for AZ-104.

Azure Monitor building blocks

• Azure Monitor collects two core data types: metrics (numerical, time-series, lightweight) and logs (structured records queried with Kusto Query Language, KQL).
• Metrics are stored for 93 days by default in the platform metrics database.
• Logs are sent to a Log Analytics workspace; default retention is 30 days (interactive retention configurable 30-730 days on the workspace).
• Diagnostic settings route resource logs and metrics to a Log Analytics workspace, Storage account, or Event Hub - a resource is not monitored in depth until a diagnostic setting is created.

Activity Log vs resource logs

• The Activity Log records subscription-level control-plane events (who did what, when) and is retained 90 days automatically, with no configuration needed.
• Resource logs (data-plane operations, e.g. inside a VM or storage account) require an explicit diagnostic setting and are NOT enabled by default.
• A common exam trap: assuming resource logs exist automatically like the Activity Log - they don't.

Alerts

• Alert rules have three parts: signal (metric, log, activity log), condition/threshold, and action group.
• Action groups define the response: email, SMS, push, voice, webhook, Azure Function, Logic App, or runbook.
• Metric alerts can use static or dynamic thresholds; dynamic thresholds learn normal patterns using machine learning.
• Log alerts run a scheduled KQL query at a set frequency and fire when results meet the condition.

VM insights and diagnostics

• Azure Monitor Agent (AMA) is the current unified agent, replacing the legacy Log Analytics agent (MMA/OMS), which retired 31 August 2024.
• VM insights uses AMA plus data collection rules (DCRs) to gather performance counters and map dependencies.
• Boot diagnostics captures console output and screenshots to troubleshoot VM startup issues - stored in a storage account.

Network Watcher

• Network Watcher provides diagnostic tools: IP flow verify, Next hop, Connection troubleshoot, and Packet capture.
• NSG flow logs (version 2 preferred) record allowed/denied traffic through a network security group and can feed Traffic Analytics for visualisation.

Backup and recovery basics

• Azure Backup uses a Recovery Services vault; default backup policy for VMs is once daily, with instant restore points kept for 1-7 days.
• Soft delete keeps deleted backup data recoverable for 14 days by default, protecting against accidental or malicious deletion.
• Azure Site Recovery (ASR) handles disaster recovery/replication and is a separate service from Azure Backup, though both use a Recovery Services vault.

Common mistakes

• Forgetting resource logs need a diagnostic setting configured explicitly.
• Confusing metric alerts (fast, near real-time) with log alerts (slower, query-based, minimum 5 minute frequency).
• Assuming the legacy Log Analytics agent still works - it's retired; use AMA.

Azure Backup basics

Azure Backup uses a Recovery Services vault (RSV) to store backup data. The vault is a management and storage construct - it holds backup policies, recovery points and configuration for VMs, files, folders, SQL in Azure VMs and more.

Backups are incremental after the first full backup, reducing storage and network cost. Data is encrypted at rest automatically. You choose a redundancy setting on the vault: Locally Redundant Storage (LRS), Zone Redundant Storage (ZRS) or Geo Redundant Storage (GRS) - GRS is default and replicates to a paired region.

Soft delete and retention

Soft delete is on by default for Recovery Services vaults. If backup data is deleted (accidentally or maliciously) it is retained for 14 additional days at no extra storage cost, so you can undelete it. This defends against ransomware and accidental deletion.

Backup policies define schedule (daily or weekly) and retention (daily, weekly, monthly, yearly points), all configurable per policy and assignable to multiple VMs.

Azure Site Recovery (ASR) vs Backup

Don't confuse the two. Azure Backup protects data (restore a file, VM disk or database to a point in time). Azure Site Recovery is for disaster recovery - it replicates entire VMs to another region so you can fail over and keep the workload running with minimal downtime. Backup = data protection; ASR = business continuity.

Key security building blocks

Azure AD (Microsoft Entra ID) is the identity backbone - Conditional Access policies enforce MFA, block legacy authentication, or restrict sign-in by location/device compliance. Conditional Access needs Azure AD Premium P1 or higher.

Role-Based Access Control (RBAC) assigns permissions at management group, subscription, resource group or resource scope, and is additive (deny assignments override allow). Built-in roles: Owner (full control + can assign roles), Contributor (full control, no role assignment), Reader (view only). Least privilege is the exam's constant theme.

Azure Key Vault stores secrets, keys and certificates centrally, avoiding hard-coded credentials. Access via access policies or (recommended) Azure RBAC on the vault.

Network Security Groups (NSGs) filter traffic by 5-tuple rules with a priority number 100-4096 - lower number = higher priority, first match wins. Azure Firewall provides centralised, stateful filtering across a hub network. Azure DDoS Protection has two tiers: Basic (free, automatic) and the paid tier (Network Protection - formerly Standard - adds attack analytics, cost protection and rapid support).

Common exam traps

• Deleting a VM does not delete its recovery points - you must stop protection with delete data explicitly, or they remain billed.
• Backup policy retention is separate from soft delete retention (the extra 14 days).
• NSGs work at subnet or NIC level; rules are stateful for the initiating direction only.
• Changing vault storage redundancy (LRS to GRS) is only allowed before the first backup runs.