Azure Architecture & Services
A four-level hierarchy organizes every Azure resource, and governance and access inherit down it
Assuming the cloud-concepts domain is behind you, by the end of this one you will be able to place any architecture or core-service scenario in the right part of Azure. The backbone is a hierarchy: Azure arranges everything into management group → subscription → resource group → resource: every resource lives in exactly one resource group, every resource group belongs to one subscription (the billing, quota, and access boundary), and subscriptions can nest under management groups for org-wide control. Crucially, both Azure Policy and Azure role-based access control (RBAC) role assignments inherit downward, so a rule set at a high scope automatically applies to everything beneath it. This is why the management hierarchy is the spine of the whole domain: apply broad governance and roles high, place narrow exceptions low. A claim that a resource group is a billing boundary is wrong: cost and quotas are scoped to the subscription, and a resource group can even span regions.
Physical placement is a deliberate trade between latency, availability, and data residency
Azure's footprint nests geography → region → availability zone → datacenter, and each level answers a different design question. You pick a region at deployment for latency and feature/price availability; you spread replicas across availability zones (a zone-enabled region has at least three) for high availability against a single-datacenter failure; and you rely on region pairs (~300+ miles apart, same geography, with sequential updates and recovery priority) for disaster recovery against losing a whole region. A geography (and a sovereign region such as Azure Government or Azure operated by 21Vianet) exists to keep data inside a legal jurisdiction. Treating zones and region pairs as interchangeable is a common error: zones are HA within a region, region pairs are DR across regions.
Across compute, storage, and connectivity you trade control for managed convenience
The same dial recurs through the workload services. Compute spans Virtual Machines (IaaS, full OS you patch), containers (ACI, AKS, Azure Container Apps), and Functions (serverless, pay-per-execution); app hosting likewise runs on a VM (full control), a container, or Azure App Service (PaaS, Microsoft patches and scales). Storage trades storage cost for access cost across Hot, Cool, Cold, and Archive tiers, and trades durability scope between single-region (LRS, ZRS) and cross-region (GRS, GZRS) redundancy. Connectivity trades cost for assurance between VPN Gateway (encrypted tunnel over the public internet) and ExpressRoute (private dedicated circuit that bypasses it). In each case the higher-managed, higher-assurance option costs more: pick by the workload's real requirement, not by default.
Identity is the perimeter that secures every other service, layered behind defense-in-depth and Zero Trust
Microsoft Entra ID (formerly Azure AD) is the front door: it authenticates principals (proving who you are) while Azure RBAC authorizes them (deciding what they may do) by binding a principal to a role at a scope that inherits down the same hierarchy as policy. Sign-in is strengthened with SSO, MFA (two or more factor categories, never two of the same), passwordless, and Conditional Access that applies controls only when sign-in signals warrant. Around this spine sit defense-in-depth (independent layers from physical to data, with data innermost) and Zero Trust (verify explicitly, least privilege, assume breach), monitored by Microsoft Defender for Cloud with its Secure Score across Azure, hybrid, and multicloud. Because the identity-and-RBAC layer gates access to compute, storage, and networking alike, it underpins the entire domain rather than being one service among many.