Resource group
What it is
A resource group is a logical container for Azure resources that share a lifecycle: you expect to deploy, update, and eventually retire them together. A resource group belongs to one subscription. Most application resources belong to one resource group, although Azure also supports specific resource types at subscription, management-group, or tenant scope.
Why it exists
Instead of managing every resource in isolation, you group the resources of an application/lifecycle into one container so you can deploy, update, delete, monitor, and secure them as a unit — and apply RBAC and Azure Policy at that scoped boundary.
Key ideas
- One place, one owner — a resource can be in only one RG (but can later be moved between RGs/subscriptions).
- RG location ≠ resource locations. The RG’s region is where the RG’s metadata is stored; the resources inside it can be in any region. This is a classic trap.
- Lifecycle unit — deleting a RG deletes all resources inside it (a boundary of operation, not of geographic data residency).
- Deployment scope — ARM deployments and templates/Bicep target a RG.
- Group by lifecycle + environment, not by resource type (that’s a common anti-pattern — mixing all VMs in one RG complicates lifecycle).
Northwind example
Northwind puts the ordering web app, its storage account, and its monitoring resources in orders-production because the team deploys and retires that solution together. It puts a shared network or a database with a different owner and retirement schedule in another resource group, even if the application connects to it. Connections can cross resource-group boundaries.
Deleting orders-production would delete its resources. That makes the group a convenient lifecycle boundary, but a dangerous one to use as a casual folder. Before deleting it, Northwind must understand every contained resource and retain backups where recovery is required.
Common confusion
- The resource group’s location stores resource-management metadata. It does not force every contained resource or its customer data into that region.
- A resource group is not an availability zone, virtual network, or security boundary. RBAC and Policy can be scoped to it, but networking and resiliency need their own design.
- Tags on a resource group do not automatically flow to its resources.
How it fits (diagram)
Diagrams courtesy of Microsoft Learn / Azure docs: azure-resource-manager/management/manage-resource-groups-portal
Exam notes
- RG location is where metadata sits — the RG itself is not a physical place and stores no resources’ data.
- Deleting a RG deletes everything inside it.
- Move of a resource across RGs/subscriptions is possible but has constraints (recreate vs move, some resources can’t move).
- Use RG to scope RBAC assignments and policies at an application boundary.
Related
Path MOC · subscription · arm · scope · resource-tags · azure-policy
📘 Source: Microsoft Learn — Resource Group
Azure region
What it is
An Azure region is a geographic area containing one or more datacenters connected through Azure’s network. When you create a regional service, you choose a region such as eastus, westeurope, or uksouth. That choice affects the service’s location, what features are available, latency to users, pricing, and sometimes legal or organizational requirements.
Why it exists
You choose a region to place a workload near users or connected systems, to meet data-residency needs, and to use services available there. One subscription can contain workloads in many regions. Not every Azure service is regional; some are global, and service availability differs by region.
Region, zone, geography, and pair
- A zone is a separate physical-fault boundary inside a zone-enabled region. A region is not itself a zone.
- A geography is a market or area containing one or more regions and can matter for residency and compliance commitments.
- Many regions have a region pair, but a pair is not an automatic disaster-recovery solution. Cross-region replication, failover, backups, and the application’s behavior must be configured service by service.
- A sovereign cloud is a separately operated cloud environment for particular regulatory or government needs; it is not merely another public-cloud region.
How it fits (diagram)
Diagrams courtesy of Microsoft Learn / Azure docs: reliability/availability-zones-overview
Northwind example
Northwind chooses a region near its customers and warehouse systems after checking that App Service, storage, and its required reliability options are supported there. Its production subscription may also contain monitoring or recovery resources elsewhere. If Northwind later needs to serve another continent or survive a full regional outage, it designs and tests a multi-region pattern; selecting a region pair alone does not copy its application.
Common confusion
- A resource-group location is not the same as the location of every resource inside it.
- A region can contain zones, but a region with zones does not automatically make every resource zone-resilient.
- Changing a workload’s region is usually a service-specific move or redeployment, not a simple rename. Check the supported migration path before planning it.
Related
availability-zones · subscription · resource-group · northwind-traders-case-study
📘 Sources: Microsoft Learn — Azure regions and geographies and What are availability zones?, checked 2026-09-16.
Microsoft Entra ID (formerly Azure Active Directory)
What it is
Microsoft Entra ID is Microsoft’s cloud-based identity and access-management service. It stores identities such as people, groups, devices, and applications; verifies a sign-in (authentication, “who are you?”); and can enforce sign-in policies. It was formerly called Azure Active Directory (Azure AD).
Why it exists
An organization needs one place to recognize its people and workloads across Azure, Microsoft 365, and connected apps—without running cloud domain controllers. An Entra tenant is that organization’s isolated directory.
Key ideas
- Tenant: the isolated Entra directory for an organization. An Azure subscription trusts one tenant for identity.
- Directory objects: users, groups, devices, applications, service principals, and managed identities.
- Single sign-on (SSO): after a successful Entra sign-in, connected applications can reuse that identity experience instead of each asking for a separate password.
- Policy is contextual: Conditional Access can require controls such as MFA based on the sign-in and policy conditions.
- Not a domain controller: Entra ID can join and manage modern devices, but it is not Windows Server AD DS. A legacy workload needing LDAP, Kerberos/NTLM, or Group Policy needs AD DS-compatible services.
Components relevant to AZ-104
- Users & groups
- Service principals & managed identities (how apps authenticate)
- MFA, SSPR, Conditional Access
- Microsoft Entra roles
- App registrations / Enterprise apps
Relationship to RBAC
Azure RBAC authorizes access to Azure resources. Entra ID supplies the identity RBAC evaluates. Entra also has directory roles for managing Entra objects. In short: Entra helps establish who or what is asking; the assigned role and scope decide what that identity may do.
Northwind example
Maya creates an Entra group named Northwind-Platform-Admins, then assigns that group an Azure role at the appropriate scope. When Luis joins the platform team, Maya adds him to the group instead of making several separate role assignments. A Conditional Access policy asks Luis for MFA when its conditions require it. The group is not the resource permission by itself—it is a convenient way to give the same assignment to the right people.
Diagram
Diagrams courtesy of Microsoft Learn / Azure docs: entra/identity/entra-overview
Exam notes
- Entra ID = cloud identity, authentication, and policy layer. Azure RBAC = Azure-resource authorization layer.
- Rebranded from Azure AD in 2023; the exam may still reference “Azure AD” — same thing.
- A tenant = the container for identities; a subscription = a container for resources that trusts a tenant.
Related
rbac · user-account · service-principal · mfa · conditional-access · tenant
📘 Sources: Microsoft Learn — What is Microsoft Entra? and Azure AD naming change.
Azure Policy
What it is
Azure Policy is Azure’s rules engine for resource configuration. It compares resources and management actions with rules your organization assigns, such as “deploy only in approved regions” or “add a cost-center tag.” It can report a mismatch, block a non-compliant change, alter a resource, or deploy related configuration, depending on the policy effect.
Why it exists
People make mistakes. Policy lets an org codify governance so non-compliant resources are automatically flagged (and optionally prevented/denied) at scale across subscriptions — regardless of who creates them.
The pieces
- A definition states one rule. Azure supplies built-ins and organizations can create custom definitions.
- An initiative groups several definitions for one goal, such as a security baseline.
- An assignment applies a definition or initiative at a scope. Child scopes inherit it unless excluded.
- The effect says how Azure responds.
Auditreports non-compliance;Denyprevents the non-compliant create or update;ModifyorDeployIfNotExistscan change or add supported configuration and can require remediation for existing resources.
Northwind example
Maya assigns an “allowed locations” policy to Northwind’s Production management group. When Luis tries to create a production VM in an unapproved region, a Deny effect blocks the request even if his RBAC role lets him create VMs. A different tagging policy first uses Audit, so Northwind can see which resources lack a costCenter tag before deciding whether to use Modify or Deny.
This example shows the division of labor: RBAC asks whether Luis may create a VM; Policy asks whether the requested VM configuration follows Northwind’s rule.
Use it safely
Start an unfamiliar policy in audit mode when practical. Review existing resources, automation, exclusions, and remediation permissions before enforcing with Deny, Modify, or DeployIfNotExists. A policy assignment is powerful at a management-group scope: one mistaken rule can affect many subscriptions.
Common confusion
- Policy does not replace RBAC. It normally does not grant a user permission to act.
- A policy definition alone does nothing until it is assigned to a scope.
- A compliance report does not automatically fix existing resources. Remediation is effect- and resource-specific.
- A more-permissive child assignment does not override an inherited deny. Change or exclude the broader assignment instead.
How it fits (diagram)
Diagrams courtesy of Microsoft Learn / Azure docs: azure-policy/overview
Where it appears in the route
Read azure-management-hierarchy and scope before using this entry in AZ-104 foundation.
Related
management-groups · scope · rbac · resource-tags · northwind-traders-case-study
📘 Source: Microsoft Learn — Azure Policy overview, checked 2026-09-16.