My experience is that the terminology around tenants and landing zones is not used consistently everywhere. What I have found helpful is to understand the terms and use them like this.
- At what level landing zones are created? Like are they created on resource group level, subscription level, tenant level or any other level.
A landing zone defines the set up of the environment for a development team. A "one size fits all" landing zone approach doesn't work very well, especially when teams have very different demands of their cloud environments. For example, an team doing IaaS lift & shift may be very happy with a resource group that gives them a subnet (feels like on-premise), whereas a team developing serverless applications wants a subscription of their own. So you should prepare your AAD tenant to host multiple landing zones, segregated by Management Group structure.
- Also, in a multi tenant architecture, do different tenants share the same landing zone ?
A tenant defines a unit of isolation in a multi-tenant infrastructure. When applied to azure, we should always clarify what kind of a tenant we're talking about. An "AAD Tenant" is a unit of isolation in the global AAD service (all of Microsoft's customers), whereas a "landing zone tenant" is a customer of your landing zone.
From the IaaS lift&shift landing zone example above, your landing zone may be a subscription with a vnet (shared infrastructure). Each of your customers then receives a tenant in that landing zone in the form of a resource group with a subnet. In the serverless landing zone example, the shared infrastructure is the AAD tenant, management group, policies etc.
So in summary, a landing zone always consists of some shared infrastructure that establishes guard rails about how its tenants can use and consume cloud services and a mechanism for provisioning/deprovisioning tenants in that landing zone.