TL;DR: A tenant is your Entra ID directory, management groups organise subscriptions for policy inheritance, a subscription is the billing and quota boundary, and a resource group is a lifecycle container you can delete in one action. Put the boundaries where quotas and blast radius need them, because moving resources afterwards is awkward.
How to approach it
Give the four levels and say what each one is a boundary for, since that is what decides a design. If you have AWS experience, map it out loud: a subscription is roughly an account, a management group is roughly an organisational unit, and a resource group has no AWS equivalent at all, which is the piece people trip over.
A strong answer
Tenant. Your Microsoft Entra ID directory, the identity boundary. Users, groups and application registrations live here. One organisation normally has one tenant, and everything else hangs off it. Cross-tenant access is deliberately awkward, which matters during a merger.
Management groups. A tree above subscriptions, existing so that governance applies once and inherits down. Assign an Azure Policy or an RBAC role at a management group and every subscription under it gets it. A typical shape is a root, then Platform and Landing Zones, then Production and Non-Production beneath. Six levels are allowed, and two or three are usually enough; deep trees make it hard to reason about where a permission came from.
Subscription. The boundary that has real operational weight. It carries billing, so a subscription is the natural unit for cost reporting, and it carries quotas, which is the one people learn the hard way: vCPU limits per region are per subscription, so a busy workload can exhaust capacity and starve everything else in the same subscription. It is also an RBAC boundary and a blast-radius boundary.
Resource group. A container for resources that share a lifecycle. This has no AWS equivalent and it is the most useful thing in the hierarchy. A resource group is a unit you can delete, and deleting it deletes everything inside, which makes it an excellent fit for an environment or an application instance. A resource group has a location, which is only where its metadata lives; the resources inside can be in other regions.
The practical rules that follow:
Group by lifecycle, not by type. A resource group per application per environment works because everything in it is created and destroyed together. A resource group called all-storage-accounts is a filing cabinet, not a lifecycle, and it cannot be deleted safely.
Split subscriptions by quota and blast radius, not by team sentiment. Production separate from non-production, always. A large workload with its own capacity needs probably deserves its own subscription.
Apply policy high and RBAC low. Azure Policy at a management group enforces things like allowed regions, required tags and denied public IPs across everything below. Access assignments belong at a resource group or subscription, so a team gets exactly their scope.
Tag from the start. Cost allocation in Azure depends heavily on tags, and retro-fitting them across thousands of resources is a project. Enforce required tags through policy so a resource without them cannot be created.
Where this gets a name: a landing zone is this design applied in advance, so subscriptions arrive already wired with networking, policy, logging and identity rather than being built by hand each time.
What interviewers probe next
"Can you move a resource between resource groups or subscriptions?" Often yes, and it varies by resource type and can involve downtime or a changed resource ID. Treat it as possible but unpleasant, which is the argument for getting the boundary right at creation.
"How is this different from AWS?" Subscription maps to account, management group to organisational unit, Azure Policy to a service control policy. The difference is the resource group, and the fact that Azure identity sits in one tenant across all subscriptions rather than being per account.
"What happens when a subscription hits a quota?" Deployments fail with a quota error, and the increase is a support request rather than a setting. Tracking quota headroom per subscription and region is ordinary operational work, not an exception.
Common mistakes
Grouping resources by type rather than lifecycle, which makes the delete-the-group property useless.
Running production and development in one subscription, so a test workload can exhaust the quota production needs.
Assigning permissions at the subscription when the team only needs a resource group.
Leaving tagging until the finance conversation, when enforcing it at creation costs nothing.