Free guides, interview Q&As, and job responsibility breakdowns — curated by industry veterans to help you crack MNC interviews
Azure Role-Based Access Control (Azure RBAC) is Microsoft Azure's authorization system that helps organizations control who can access Azure resources and what actions they can perform. Instead of giving every user full control, Azure RBAC allows administrators to assign only the required permissions based on the user's job role.
RBAC improves security, simplifies access management, and ensures that users have only the permissions they need.
Definition
Azure Role-Based Access Control (Azure RBAC) is an authorization system in Microsoft Azure that allows administrators to assign permissions to Users, Groups, Service Principals, or Managed Identities based on their roles.
(Azure RBAC Microsoft Azure की एक Authorization प्रणाली है, जिसकी मदद से Users, Groups या अन्य Security Principals को उनके कार्य के अनुसार अलग-अलग Roles और Permissions दिए जाते हैं।
इसका उद्देश्य यह सुनिश्चित करना है कि प्रत्येक User केवल उन्हीं Resources का उपयोग कर सके, जिनकी उसे वास्तव में आवश्यकता है।)
Explanation
In an organization, different employees perform different tasks. For example, an IT Administrator may need full control over Azure resources, while a developer may only need permission to create Virtual Machines. Similarly, a manager may only need to view resource information.
Instead of giving every user full access, Azure RBAC allows administrators to assign specific roles with predefined permissions. This improves security and prevents unauthorized changes.
Azure RBAC follows the principle of "Right User, Right Role, Right Resource."
Example
Suppose a company has three employees:
Using Azure RBAC:
Each user can perform only the actions allowed by their assigned role.
Organizations use Azure RBAC to securely manage access to Azure resources.
Without RBAC, every user would have the same permissions, which could lead to accidental changes, data loss, or security risks.
RBAC ensures that users receive only the permissions required to perform their job responsibilities.
(बड़ी संस्थाओं में सभी Users का काम एक जैसा नहीं होता। यदि सभी Users को सभी Resources पर पूरा नियंत्रण दे दिया जाए, तो गलती से महत्वपूर्ण Resources में बदलाव हो सकता है या वे हट भी सकते हैं।
Azure RBAC की मदद से प्रत्येक User को उसके कार्य के अनुसार केवल आवश्यक Permissions ही दी जाती हैं। इससे Azure Environment अधिक सुरक्षित रहता है और Resources का प्रबंधन भी आसान हो जाता है।)
Example
In a company:
Azure RBAC provides several benefits to organizations:
(Azure RBAC का उपयोग करने से Azure Resources अधिक सुरक्षित रहते हैं। प्रत्येक User को उसके कार्य के अनुसार ही Permissions मिलती हैं, जिससे अनावश्यक पहुँच रुकती है।
यह बड़े संगठनों में Users और Resources का प्रबंधन आसान बनाता है तथा गलती से होने वाले बदलावों और सुरक्षा संबंधी जोखिमों को कम करता है।)
Example
A company assigns:
As a result, every employee can perform only the tasks required for their job, improving both security and resource management.
Before understanding Azure RBAC, it is important to revise the concepts of Authentication and Authorization. Whenever a user tries to access an Azure resource, the system first verifies the user's identity and then checks what actions the user is allowed to perform.
Definition
Authentication is the process of verifying the identity of a User, Device, or Application before granting access to a system or resource.
(Authentication वह प्रक्रिया है जिसमें सिस्टम यह जाँच करता है कि User वास्तव में वही है जो वह अपने आपको बता रहा है। यदि उसकी पहचान सही मिलती है, तभी उसे Sign In करने की अनुमति दी जाती है।)
Explanation
Authentication verifies the identity of a user using credentials such as:
If the provided credentials are correct, the user is successfully authenticated.
Example
A user enters the following credentials to sign in to Azure Portal:
Azure verifies the credentials. If they are correct, the user is authenticated.
Definition
Authorization is the process of determining what resources a user can access and what actions they are allowed to perform after successful authentication.
(Authorization वह प्रक्रिया है जिसमें सिस्टम यह तय करता है कि User को कौन-कौन से Resources का उपयोग करने और उन पर कौन-कौन से कार्य करने की अनुमति है।)
Explanation
After a user is authenticated, Azure checks the user's assigned Role through Azure RBAC and decides whether the requested action is allowed or denied.
Example
After Rahul signs in successfully:
| Authentication | Authorization |
| Verifies the identity of a User | Determines what the User can access |
| Happens first | Happens after Authentication |
| Checks Username, Password, OTP, or MFA | Checks Roles and Permissions |
| Answers "Who are you?" | Answers "What are you allowed to do?" |
| Example: Signing in to Azure | Example: Creating or Managing Azure Resources |
(Authentication का काम User की पहचान की जाँच करना है, जबकि Authorization का काम यह तय करना है कि उस User को कौन-कौन से Resources का उपयोग करने और उन पर कौन-कौन से कार्य करने की अनुमति है। Azure में यह अनुमति Azure RBAC द्वारा नियंत्रित की जाती है।)
Azure Role-Based Access Control (Azure RBAC) controls access to Azure resources using three core components. These components work together to determine:
Whenever an administrator assigns a role in Azure, these three components are always involved.
The three core components of Azure RBAC are:
Definition
A Security Principal is an identity that can be assigned a role in Azure RBAC. It represents who receives permissions to access Azure resources.
A Security Principal can be a User, Group, Service Principal, or Managed Identity.
(Security Principal वह Identity होती है जिसे Azure RBAC में कोई Role दिया जाता है। सरल शब्दों में, यह बताता है कि Permission किसे दी जाएगी। यह User, Group, Application (Service Principal) या Managed Identity हो सकती है।)
Explanation
Whenever an administrator assigns a role in Azure, the first step is selecting the Security Principal.
Azure needs to know who should receive the permission. That identity becomes the Security Principal.
Azure supports four types of Security Principals:
Instead of assigning permissions to every individual user, administrators often assign roles to Groups. Every member of that Group automatically receives the assigned permissions.
Example
A company has an employee named Rahul.
The administrator assigns the Contributor role to Rahul.
Here,
Security Principal → Rahul
Assigned Role → Contributor
Similarly, if the administrator assigns the role to the IT Team Group, then every member of that group receives the same permissions.
Definition
A Role Definition is a collection of permissions that defines what actions a Security Principal is allowed to perform on Azure resources.
It specifies what the user can do after access is granted.
(Role Definition उन Permissions का समूह होता है जो यह तय करता है कि किसी Security Principal को Azure में कौन-कौन से कार्य करने की अनुमति होगी।)
Explanation
A Role Definition contains a predefined set of permissions.
Instead of assigning permissions one by one, Azure provides Roles that already contain the required permissions.
For example, some users may only need permission to view resources, while others need permission to create or modify resources.
Azure provides many built-in roles such as:
Organizations can also create Custom Roles if the built-in roles do not meet their requirements.
Role Definitions help maintain consistency and improve security by ensuring users receive only the permissions required for their job.
Example
Suppose Rahul is assigned the Reader role.
Rahul can:
Rahul cannot:
The Role Definition determines exactly what Rahul is allowed to do.
Definition
Scope defines the boundary or level at which a role assignment is applied in Azure.
It specifies where the assigned permissions are valid.
(Scope यह तय करता है कि किसी Role द्वारा दी गई Permission Azure में कहाँ तक लागू होगी। दूसरे शब्दों में, Permission किस स्तर तक प्रभावी रहेगी, यह Scope निर्धारित करता है।)
Explanation
A role can be assigned at different levels in Azure.
Azure provides four levels of Scope:
Permissions assigned at a higher level are automatically inherited by lower levels.
For example:
Example
Suppose an administrator assigns Rahul the Contributor role at the Resource Group level.
Rahul can:
However, Rahul cannot access or modify resources located in other Resource Groups unless another role is assigned.
Azure RBAC works only when all three components are combined.
The process is as follows:
Only after these three components are combined does Azure allow the Security Principal to perform the permitted actions.
(Azure RBAC में सबसे पहले यह तय किया जाता है कि Permission किसे दी जाएगी (Security Principal)। इसके बाद यह तय किया जाता है कि उसे कौन-कौन सी Permissions मिलेंगी (Role Definition)। अंत में यह निर्धारित किया जाता है कि वे Permissions Azure में किस Scope तक लागू होंगी। इन तीनों के एक साथ कार्य करने पर ही Azure किसी User को Resource का उपयोग करने की अनुमति देता है।)
Complete Example
Suppose a company wants Rahul to manage Virtual Machines in the Development Resource Group.
The administrator assigns:
As a result:
Rahul can create, modify, and delete resources only within the Development Resource Group.
Rahul cannot access resources in the Production Resource Group because the role is limited by its Scope.
Azure provides several Built-in Roles that contain predefined sets of permissions. Instead of creating permissions manually for every user, administrators can assign these built-in roles based on the user's job responsibilities.
Each Built-in Role is designed for a specific level of access, making permission management easier and more secure.
The four most commonly used Built-in Roles are:
Definition
Built-in Roles are predefined roles provided by Microsoft Azure that contain a predefined set of permissions. These roles allow administrators to assign the appropriate level of access to Users, Groups, or other Security Principals without creating permissions manually.
(Built-in Roles Microsoft Azure द्वारा पहले से बनाए गए Roles होते हैं। प्रत्येक Role में आवश्यक Permissions पहले से निर्धारित होती हैं। Administrator आवश्यकता के अनुसार इन Roles को Users, Groups या अन्य Security Principals को सौंप सकता है।)
Explanation
Managing permissions individually for every user in a large organization is difficult and time-consuming. To simplify access management, Azure provides Built-in Roles.
Each role grants a different level of access. For example, some users may only need to view resources, while others may need to create, modify, or manage them.
By assigning the appropriate Built-in Role, organizations can ensure that users receive only the permissions required for their work.
Azure currently provides hundreds of Built-in Roles, but the four most commonly used roles are:
Example
A company has three employees:
Each employee receives permissions according to their responsibilities.
Definition
The Owner role provides full management access to all Azure resources. In addition to managing resources, the Owner can also assign roles and manage access for other users.
(Owner Azure का सबसे उच्च Built-in Role है। इस Role वाले User को सभी Azure Resources पर पूरा नियंत्रण प्राप्त होता है। वह Resources का प्रबंधन करने के साथ-साथ अन्य Users को Roles भी सौंप सकता है।)
Explanation
The Owner role has the highest level of permission in Azure RBAC.
An Owner can:
Because this role provides unrestricted access, it should be assigned only to trusted administrators.
Example
Rahul is the Azure Administrator of a company.
He is assigned the Owner role.
Rahul can:
Definition
The Contributor role allows users to create, modify, and delete Azure resources, but it does not allow them to assign roles or manage access permissions.
(Contributor Role वाले User अधिकांश Azure Resources का प्रबंधन कर सकते हैं, लेकिन वे किसी अन्य User को Role नहीं दे सकते और Permissions में बदलाव नहीं कर सकते।)
Explanation
The Contributor role is commonly assigned to developers, system engineers, and application administrators.
A Contributor can perform almost every resource management task except access management.
This ensures that users can manage resources without affecting the organization's security settings.
Example
Amit is a Cloud Engineer.
He is assigned the Contributor role.
Amit can:
Definition
The Reader role allows users to view Azure resources and their configuration but does not allow them to create, modify, or delete resources.
(Reader Role वाले User केवल Azure Resources को देख सकते हैं। वे किसी भी Resource में बदलाव, निर्माण या हटाने का कार्य नहीं कर सकते।)
Explanation
The Reader role is ideal for managers, auditors, and support teams who only need to monitor resources.
Since the Reader role provides read-only access, it helps maintain security while allowing users to access important information.
Example
Neha is an Auditor.
She is assigned the Reader role.
Neha can:
Neha cannot:
Definition
The User Access Administrator role allows users to manage access to Azure resources by assigning or removing RBAC roles. However, it does not provide permission to manage the resources themselves.
(User Access Administrator Role वाले User का मुख्य कार्य Azure RBAC Roles को Assign, Remove और Manage करना होता है। यह Role Resources का प्रबंधन नहीं करता, बल्कि Permissions का प्रबंधन करता है।)
Explanation
This role is mainly used by security administrators or identity administrators who are responsible for controlling access.
A User Access Administrator can:
However, this role cannot create or modify Azure resources unless another role has been assigned.
Example
Priya is the Identity Administrator.
She is assigned the User Access Administrator role.
Priya can:
Priya cannot:
| Permission | Owner | Contributor | Reader | User Access Administrator |
| View Resources | ✔ | ✔ | ✔ | ✔ |
| Create Resources | ✔ | ✔ | ✖ | ✖ |
| Modify Resources | ✔ | ✔ | ✖ | ✖ |
| Delete Resources | ✔ | ✔ | ✖ | ✖ |
| Assign RBAC Roles | ✔ | ✖ | ✖ | ✔ |
| Manage Resource Access | ✔ | ✖ | ✖ | ✔ |
(Owner को सबसे अधिक अधिकार प्राप्त होते हैं। Contributor Resources का प्रबंधन कर सकता है लेकिन Roles नहीं दे सकता। Reader केवल Resources को देख सकता है। User Access Administrator केवल Permissions और Role Assignments का प्रबंधन करता है।)
Real-World Example
Suppose a company has the following employees:
| Employee | Role Assigned | Responsibility |
| Rahul | Owner | Manage all Azure resources and user access |
| Amit | Contributor | Develop and manage Azure resources |
| Neha | Reader | Monitor and audit Azure resources |
| Priya | User Access Administrator | Manage user permissions and RBAC roles |
Each employee receives only the permissions required for their job, improving security and reducing the risk of unauthorized changes.
While Azure provides many Built-in Roles, there may be situations where an organization needs a specific set of permissions that are not available in any existing role. In such cases, Azure allows administrators to create Custom Roles.
Custom Roles help organizations provide users with only the permissions required for their specific job responsibilities, improving both flexibility and security.
Definition
A Custom Role is a user-defined role in Azure RBAC that contains a customized set of permissions created by an administrator to meet specific business or organizational requirements.
(Custom Role Azure RBAC में Administrator द्वारा बनाया गया एक विशेष Role होता है। इसमें संस्था अपनी आवश्यकता के अनुसार Permissions जोड़ या हटा सकती है, ताकि User को केवल वही अधिकार मिलें जिनकी उसे वास्तव में आवश्यकता है।)
Explanation
Azure provides hundreds of Built-in Roles, but sometimes they do not exactly match an organization's requirements.
For example:
Example
A company wants its developers to:
But they should not:
The administrator creates a Custom Role containing only these permissions and assigns it to the developers.
Organizations use Custom Roles when the available Built-in Roles do not meet their security or business requirements.
Instead of giving users unnecessary permissions, administrators can create roles that contain only the required actions.
(हर संस्था की आवश्यकताएँ अलग-अलग होती हैं। कई बार Built-in Roles में या तो बहुत अधिक Permissions होती हैं या बहुत कम।
ऐसी स्थिति में Custom Role बनाया जाता है, ताकि User को केवल वही Permissions मिलें जिनकी उसे अपने कार्य के लिए आवश्यकता है। इससे Security भी बेहतर रहती है और अनावश्यक Access भी नहीं मिलता।)
Example
A company wants an employee to manage only Azure Storage Accounts.
Instead of assigning the Contributor role, which allows management of many Azure resources, the administrator creates a Storage Manager Custom Role that permits management of only Storage Accounts.
This provides exactly the required level of access.
Scenario
A company has a Backup Team responsible only for managing Azure Backup services.
The team should be able to:
The team should not be able to:
The administrator creates a Backup Operator Custom Role with only the required permissions and assigns it to the Backup Team.
As a result:
The organization maintains better security and follows the Principle of Least Privilege.
| Built-in Role | Custom Role |
| Created and managed by Microsoft | Created and managed by the organization |
| Contains predefined permissions | Contains customized permissions |
| Suitable for common administrative tasks | Suitable for specific business requirements |
| Cannot be modified | Can be customized according to organizational needs |
(Built-in Roles सभी संस्थाओं के सामान्य उपयोग के लिए बनाए गए हैं, जबकि Custom Roles किसी संस्था की विशेष आवश्यकताओं के अनुसार बनाए जाते हैं।)
In Azure RBAC, assigning a role alone is not enough. Azure also needs to know where that role should apply. This is determined by the Scope.
The Scope defines the boundary within which a user can perform the actions allowed by their assigned role. Azure provides four levels of Scope, allowing organizations to control access from the entire organization down to a single resource.
The four levels of RBAC Scope are:
Definition
Scope is the boundary or level at which an Azure RBAC role assignment is applied. It determines where the assigned permissions are valid.
(Scope वह सीमा या स्तर होता है जहाँ तक किसी Role द्वारा दी गई Permissions लागू होती हैं। यह तय करता है कि User Azure में किन Resources पर अपने Role के अनुसार कार्य कर सकता है।)
Explanation
When an administrator assigns a role to a user, they must also specify the Scope.
For example, if a user is assigned the Reader role at the Subscription level, they can view all Resource Groups and Resources within that Subscription.
However, if the same role is assigned only at the Resource Group level, the user can view only the resources inside that Resource Group.
Choosing the correct Scope is important because it prevents users from receiving unnecessary access and helps organizations follow security best practices.
Example
Suppose Rahul is assigned the Contributor role.
If the scope is subscription, Rahul can manage resources across the entire subscription.
If the scope is a resource group, Rahul can manage only the resources within that resource group.
Definition
A management group is the highest level of scope in Azure RBAC. It is used to organize and manage multiple Azure subscriptions under a single hierarchy.
(Management Group Azure RBAC का सबसे बड़ा Scope है। इसका उपयोग कई Subscriptions को एक साथ व्यवस्थित करने और उन पर एक जैसी Policies तथा Permissions लागू करने के लिए किया जाता है।)
Explanation
Large organizations often have multiple Azure Subscriptions for different departments, projects, or business units.
Instead of assigning roles separately to each Subscription, administrators can assign a role at the Management Group level.
All Subscriptions inside that Management Group automatically inherit the assigned permissions.
This simplifies administration and ensures consistent access management across the organization.
Example
A company has three Subscriptions:
If Rahul is assigned the Reader role at the Management Group level, he can view resources in all three Subscriptions.
Definition
A Subscription is the second level of Scope in Azure RBAC. It represents a billing and management boundary that contains Azure Resources.
(Subscription Azure का वह स्तर है जिसके अंतर्गत Resource Groups और Resources बनाए जाते हैं। यदि किसी Role को Subscription स्तर पर दिया जाता है, तो वह उस Subscription के सभी Resources पर लागू होता है।)
Explanation
Every Azure Resource belongs to a Subscription.
When a role is assigned at the Subscription level, the user automatically receives the same permissions for all Resource Groups and Resources inside that Subscription.
This Scope is commonly used for department administrators or project administrators.
Example
Rahul is assigned the Contributor role at the Development Subscription.
Rahul can create, modify, and delete resources within that Subscription but cannot manage resources in another Subscription.
Definition
A Resource Group is a logical container that holds related Azure Resources. It is the third level of Scope in Azure RBAC.
(Resource Group कई संबंधित Azure Resources का एक Logical Container होता है। यदि Role इस स्तर पर दी जाती है, तो उसकी Permissions केवल उसी Resource Group तक सीमित रहती हैं।)
Explanation
Organizations often create separate Resource Groups for different projects or applications.
Assigning roles at the Resource Group level limits user access to only that project.
This provides better security and simplifies resource management.
Example
A company has two Resource Groups:
He can manage resources in HR-RG but cannot access or modify resources in Finance-RG.
Definition
A Resource is the lowest level of Scope in Azure RBAC. It represents an individual Azure service such as a Virtual Machine, Storage Account, or Virtual Network.
(Resource Azure RBAC का सबसे छोटा Scope है। यदि किसी Role को इस स्तर पर दिया जाता है, तो User केवल उसी एक Resource पर कार्य कर सकता है।)
Explanation
Sometimes an organization wants to provide access to only one specific resource.
Instead of granting access to an entire Resource Group or Subscription, administrators can assign a role directly to that Resource.
This provides the highest level of access control.
Example
Rahul is assigned the reader role for a single Virtual Machine.
He can view only that Virtual Machine and cannot access any other resources.
Azure RBAC follows a hierarchical structure.
Management Group
│
▼
Subscription
│
▼
Resource Group
│
▼
Resource
Permissions assigned at a higher Scope are automatically inherited by the lower Scopes.
For example:
A role assigned at the Management Group applies to all Subscriptions, Resource Groups, and Resources within that Management Group.
A role assigned at the Subscription level applies to all Resource Groups and Resources within that Subscription.
A role assigned at the Resource Group level applies only to the Resources inside that Resource Group.
A role assigned at the Resource level applies only to that specific Resource.
(Azure RBAC में Permissions ऊपर से नीचे की ओर लागू होती हैं। यदि किसी User को Management Group स्तर पर Role दी जाती है, तो वही Permissions उसके अंतर्गत आने वाले सभी Subscriptions, Resource Groups और Resources पर भी लागू हो जाती हैं।)
Real-World Example
A company has the following Azure hierarchy:
The administrator assigns:
Reader role to Rahul at the Development Subscription.
As a result:
The Principle of Least Privilege (PoLP) is one of the most important security concepts in Azure RBAC. It states that every User, Group, or Application should be given only the minimum permissions required to perform its assigned tasks.
By limiting unnecessary access, organizations can reduce security risks, prevent accidental changes, and protect critical Azure resources.
Definition
The Principle of Least Privilege (PoLP) is a security principle that states a User, Group, or Application should be granted only the minimum permissions required to perform its job, and nothing more.
(Principle of Least Privilege (PoLP) एक सुरक्षा सिद्धांत है जिसके अनुसार किसी User, Group या Application को केवल उतनी ही Permissions दी जानी चाहिए जितनी उसके कार्य को पूरा करने के लिए आवश्यक हों। उसे आवश्यकता से अधिक Access नहीं दिया जाना चाहिए।)
Explanation
In an organization, not every employee requires full access to Azure resources.
For example:
If every user is given the Owner role, anyone could accidentally delete resources, modify configurations, or assign permissions to other users. This increases the risk of security breaches and operational errors.
PoLP helps organizations assign only the required permissions, ensuring that users can perform their work without receiving unnecessary access.
Azure RBAC is designed around this principle by allowing administrators to assign the appropriate role at the appropriate scope.
Example
A company has three employees:
Each employee receives only the permissions needed for their responsibilities.
The Principle of Least Privilege is important because it improves security and reduces the chances of unauthorized or accidental changes.
Without PoLP, users may receive permissions they do not actually need. If such an account is compromised or misused, attackers may gain unnecessary access to critical Azure resources.
By following PoLP, organizations can ensure that every user has only the permissions required for their assigned tasks.
(यदि किसी User को आवश्यकता से अधिक Permissions दे दी जाएँ, तो वह जानबूझकर या गलती से महत्वपूर्ण Resources में बदलाव कर सकता है।
यदि उस User का Account किसी हमलावर के हाथ लग जाए, तो अधिक Permissions होने के कारण नुकसान भी अधिक हो सकता है।
PoLP इस जोखिम को कम करता है क्योंकि प्रत्येक User को केवल आवश्यक Permissions ही मिलती हैं।)
Scenario
A company has the following employees:
| Employee | Job Role | Assigned Azure Role |
| Rahul | Azure Administrator | Owner |
| Amit | Cloud Engineer | Contributor |
| Neha | Project Manager | Reader |
| Priya | Identity Administrator | User Access Administrator |
In this example:
Each employee receives only the permissions required for their responsibilities.
This is a practical implementation of the Principle of Least Privilege.
Suppose a company hires an intern to monitor Virtual Machines.
The intern only needs to check whether the Virtual Machines are running properly.
Instead of assigning the Contributor role, the administrator assigns the Reader role.
As a result:
This is an excellent example of the Principle of Least Privilege in practice.
As organizations grow, they often use multiple Azure Subscriptions for different departments, projects, or environments such as Development, Testing, and Production. Managing each Subscription individually can become difficult.
To simplify administration, Azure provides Management Groups. A Management Group allows administrators to organize multiple Subscriptions into a hierarchy and apply the same access control, policies, and governance settings to all of them at once.
Definition
A Management Group is a logical container in Microsoft Azure that is used to organize and manage multiple Azure Subscriptions under a single hierarchy.
It helps administrators apply Azure RBAC roles, Azure Policies, and governance settings to multiple Subscriptions from one central location.
(Management Group Microsoft Azure का एक Logical Container होता है, जिसका उपयोग कई Subscriptions को एक ही स्थान पर व्यवस्थित करने और उनका प्रबंधन करने के लिए किया जाता है।
इसके माध्यम से Administrator एक ही बार में कई Subscriptions पर Roles, Policies और अन्य Management Settings लागू कर सकता है।)
Explanation
In small organizations, a single Azure Subscription may be sufficient.
However, large organizations often create separate Subscriptions for different departments or projects, such as:
Managing permissions and policies separately for each Subscription can be time-consuming.
A Management Group solves this problem by allowing administrators to place multiple Subscriptions under one hierarchy. Any Role or Policy assigned at the Management Group level is automatically inherited by all Subscriptions within that Management Group.
This provides centralized management, improves consistency, and reduces administrative effort.
Example
Suppose a company has three Azure Subscriptions:
The administrator creates a Management Group named Company-IT and places all three Subscriptions inside it.
If the Reader role is assigned at the Company-IT Management Group, users automatically receive Reader access to all three Subscriptions.
Management Groups are used to simplify the administration of multiple Azure Subscriptions.
Instead of configuring each Subscription individually, administrators can manage them from one central location.
(जब किसी संस्था में कई Subscriptions होती हैं, तो प्रत्येक Subscription पर अलग-अलग Roles, Policies और Permissions लागू करना कठिन हो जाता है।
Management Group इस समस्या का समाधान करता है। इसके माध्यम से कई Subscriptions को एक साथ व्यवस्थित किया जा सकता है और उन सभी पर एक ही स्थान से Management किया जा सकता है। इससे समय की बचत होती है और सभी Subscriptions में एक जैसी Security तथा Policies बनाए रखना आसान हो जाता है।)
Example
A company has five departments:
Each department has its own Azure Subscription.
Instead of assigning the Reader role separately to every Subscription, the administrator assigns the role once at the Management Group level.
The permission is automatically inherited by all Subscriptions within that Management Group.
The following steps can be used to create a Management Group in Azure Portal:
Enter the following details:
(Management Group बनाने के लिए सबसे पहले Azure Portal में Management Groups सेवा खोलें। इसके बाद नया Management Group बनाएँ, उसका नाम दें और आवश्यक Subscriptions उसमें जोड़ दें। इसके बाद आवश्यकता के अनुसार Roles और Policies लागू की जा सकती हैं।)
Azure uses a hierarchical structure for organizing resources.
Permissions and policies assigned at a higher level are automatically inherited by the lower levels.
For example:
Real-World Example
A multinational company has offices in:
The company creates a Management Group called Global Organization and adds all country Subscriptions to it.
The administrator then:
This allows the organization to manage all Subscriptions from a single central location instead of configuring each one individually.
Many organizations use On-Premises Active Directory (AD DS) to manage users and computers within their local network. As these organizations adopt Microsoft Azure and Microsoft 365, they need a way to keep their on-premises identities synchronized with the cloud.
Azure AD Connect is the tool that bridges this gap by synchronizing identities between the on-premises Active Directory and Microsoft Entra ID. It allows users to use the same credentials to access both on-premises and cloud resources.
Definition
Azure AD Connect is a Microsoft synchronization tool that connects an On-Premises Active Directory (AD DS) with Microsoft Entra ID, allowing users, groups, and other directory objects to be synchronized between the two environments.
(Azure AD Connect Microsoft का एक Synchronization Tool है, जो On-Premises Active Directory (AD DS) और Microsoft Entra ID को आपस में जोड़ता है।
इसकी सहायता से Users, Groups तथा अन्य Directory Objects की जानकारी On-Premises Active Directory से Microsoft Entra ID में अपने आप Synchronize हो जाती है, जिससे दोनों स्थानों पर एक जैसी जानकारी बनी रहती है।)
Explanation
Many companies already have an On-Premises Active Directory where they manage employee accounts.
When these companies start using Azure services or Microsoft 365, creating separate user accounts in Microsoft Entra ID would be time-consuming and difficult to manage.
Azure AD Connect solves this problem by automatically synchronizing user identities from the local Active Directory to Microsoft Entra ID.
As a result:
Example
A company has 500 employees whose accounts are stored in an On-Premises Active Directory.
After deploying Azure AD Connect, all employee accounts are synchronized to Microsoft Entra ID.
Employees can now sign in to Microsoft 365 and Azure services using the same credentials they use to log in to their office computers.
Organizations use Azure AD Connect to simplify identity management between on-premises and cloud environments.
Without Azure AD Connect, administrators would need to create and manage separate user accounts in both Active Directory and Microsoft Entra ID.
Azure AD Connect automatically keeps both directories synchronized, reducing administrative effort and minimizing errors.
Benefits of Azure AD Connect
Example
Whenever a new employee joins the company:
Azure AD Connect provides several important features that help organizations manage identities efficiently.
1. Directory Synchronization
Synchronizes Users, Groups, Contacts, and other directory objects between On-Premises Active Directory and Microsoft Entra ID.
2. Password Hash Synchronization (PHS)
Synchronizes a secure hash of the user's password to Microsoft Entra ID, allowing users to sign in with the same password in both environments.
3. Pass-Through Authentication (PTA)
Allows users to authenticate using the on-premises Active Directory without storing password hashes in the cloud.
4. Seamless Single Sign-On (SSO)
Enables users who are signed in to their corporate computers to access Azure services and Microsoft 365 without signing in again.
5. Automatic Synchronization
Automatically synchronizes changes made in the on-premises directory to Microsoft Entra ID.
(Azure AD Connect कई सुविधाएँ प्रदान करता है, जैसे Users और Groups का Synchronization, एक ही Password से Sign In, तथा Single Sign-On (SSO)। इससे On-Premises और Cloud दोनों स्थानों पर Identity Management सरल और प्रभावी हो जाता है।)
The synchronization process describes how identity information moves from the on-premises environment to Microsoft Entra ID.
Steps of Synchronization
A User is created or updated in the On-Premises Active Directory.
Azure AD Connect detects the changes.
The updated information is synchronized to Microsoft Entra ID.
The user can sign in to Azure services and Microsoft 365 using the synchronized account.
(जब On-Premises Active Directory में किसी User की जानकारी बनाई या बदली जाती है, तो Azure AD Connect उस परिवर्तन को पहचानता है और उसे Microsoft Entra ID में Synchronize कर देता है। इससे दोनों स्थानों पर User की जानकारी एक जैसी बनी रहती है।)
Example
Suppose a company creates a new employee account named Rahul in its On-Premises Active Directory.
Azure AD Connect automatically synchronizes Rahul's account to Microsoft Entra ID.
Rahul can then use the same username and password to:
Sign in to Azure Portal.
Access Microsoft 365.
Use other cloud services.
Modern organizations often use both On-Premises Active Directory (AD DS) and Cloud-based Microsoft Entra ID. Instead of managing separate identities for each environment, organizations use Hybrid Identity to provide users with a single identity that works across both on-premises and cloud services.
Hybrid Identity combines the advantages of traditional on-premises identity management with the flexibility and scalability of cloud identity services.
Definition
Hybrid Identity is an identity solution that integrates On-Premises Active Directory (AD DS) with Microsoft Entra ID, allowing users to access both on-premises and cloud resources using the same identity.
(Hybrid Identity ऐसी Identity Solution है जिसमें On-Premises Active Directory (AD DS) और Microsoft Entra ID को आपस में जोड़ा जाता है।
इससे Users एक ही User Account और Password का उपयोग करके On-Premises Resources तथा Cloud Services दोनों का उपयोग कर सकते हैं।)
Explanation
Many organizations already have an On-Premises Active Directory to manage employee accounts. As they move to Microsoft Azure or Microsoft 365, they also need a cloud identity system.
Instead of maintaining two separate user accounts, Hybrid Identity allows organizations to synchronize identities between On-Premises Active Directory and Microsoft Entra ID using Azure AD Connect.
This enables users to use a single identity across both environments.
Hybrid Identity simplifies user management, improves productivity, and provides a consistent sign-in experience.
Example
A company stores employee accounts in On-Premises Active Directory.
After implementing Hybrid Identity, employees use the same username and password to:
Hybrid Identity works by synchronizing identity information between On-Premises Active Directory and Microsoft Entra ID.
The synchronization is performed using Azure AD Connect.
Working Process
A User account is created in On-Premises Active Directory.
Azure AD Connect synchronizes the user information to Microsoft Entra ID.
The user signs in using the same credentials.
Microsoft Entra ID authenticates the user.
Based on the assigned permissions, the user can access both On-Premises and Cloud Resources.
(Hybrid Identity में Azure AD Connect दोनों Identity Systems को जोड़ता है।
जब On-Premises Active Directory में किसी User की जानकारी बनाई या बदली जाती है, तो वही जानकारी Microsoft Entra ID में भी Synchronize हो जाती है। इसके बाद User एक ही User Account से On-Premises और Cloud Services दोनों का उपयोग कर सकता है।)
Hybrid Identity offers several advantages for organizations that use both on-premises and cloud environments.
Benefits
(Hybrid Identity की सहायता से Users को अलग-अलग Accounts याद रखने की आवश्यकता नहीं होती।
एक ही Identity से On-Premises Resources और Cloud Services दोनों का उपयोग किया जा सकता है। इससे Identity Management आसान होता है, Security बेहतर होती है और Users का काम भी सरल हो जाता है।)
Scenario
ABC Company has:
Now:
