# User

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/user

## Quick definition

In IT, a user is anyone or anything that uses a system or service. This includes people logging into a computer or app, as well as automated services or devices that need access to resources. Users are identified by unique accounts and must prove who they are to get the right permissions.

## Simple meaning

Think of a user as the person or thing that wants to use something on a computer system. In everyday life, when you walk into a library, you are a user of that library. You have a library card that identifies you, and based on that card, you can borrow books, use the internet, or access special collections. In the IT world, a user is very similar. It can be a person sitting at a desk typing on a keyboard, but it can also be a smart thermostat sending temperature data to a cloud service, or a backup program copying files to a remote server.

To get access, a user must first prove their identity. This is usually done with a username and a password, but it can also include fingerprints, smart cards, or other methods. Once the system knows who the user is, it checks a list of rules to see what that user is allowed to do. This is called authorization. For example, a regular employee might be allowed to open documents but not delete them, while a manager can do both.

In the context of identity and governance, the concept of a user is the foundation of everything else. You cannot control access, audit activity, or enforce security policies without first defining who or what the users are. The term can sometimes be confusing because in ITIL (IT service management), a user is anyone who uses a service, even if they are not the customer who pays for it. In Microsoft Azure and security exams like SC-900, a user is usually an identity object stored in Azure Active Directory (now Microsoft Entra ID) that represents a person or a service principal.

A simple analogy is a hotel. The guests are users of the hotel rooms. The front desk authenticates them by checking their ID and reservation. The room key authorizes them to open their specific door. The cleaning robot is also a user of the elevator and hallways, but it has different permissions than a guest. Just like in IT, the hotel must manage who gets which key and for how long. If a guest checks out, their key stops working. If a new housekeeper starts, they get a key to the supply closet. This entire system of identity and access management starts with the simple but powerful concept of a user.

## Technical definition

In information technology, a user is a principal entity that interacts with a system, application, or service. This entity can be a human being, a software process, a device, or an automated service. In identity and access management (IAM), a user is typically represented by a digital identity object that includes attributes such as a unique identifier (username or userPrincipalName), authentication credentials (password, certificate, biometric template), and authorization attributes (group memberships, roles, policies).

In Microsoft Entra ID (formerly Azure AD), a user object is part of the directory schema. It has a security identifier (SID) for legacy on-premises integration and an object ID (OID) that is globally unique within the tenant. The user object can be created in the cloud, synchronized from on-premises Active Directory using Azure AD Connect, or provisioned from HR systems. Authentication methods include password hash sync, pass-through authentication, federation with ADFS, certificate-based authentication, and passwordless methods like Windows Hello for Business or FIDO2 security keys.

Authorization for users is managed through role-based access control (RBAC), attribute-based access control (ABAC), or access policies. In Azure, a user can be assigned roles at the management group, subscription, resource group, or resource level. For application access, users can be assigned to enterprise applications, and conditional access policies can enforce multi-factor authentication, device compliance, or location restrictions.

In ITIL 4, the term user is defined in the service value system. A user is a person who uses a service but may not be the service consumer (the customer) who authorizes the service. The distinction is important for service management processes like incident management, where a user reports an issue, and service request management, where a user requests something. ITIL also distinguishes between internal users (employees) and external users (customers).

From a governance perspective, users are subject to identity lifecycle management. This includes provisioning when a user joins, recertification to ensure access is still needed, and deprovisioning when a user leaves. The principle of least privilege dictates that users should only have the minimum access necessary to perform their job functions. Regular access reviews are conducted to ensure compliance.

In service management, the user concept extends to automated users like service accounts or system accounts. These are non-human identities that require similar governance to prevent security risks. Service accounts often have high privileges and are less frequently monitored, making them a common attack vector. Modern IAM solutions enforce periodic password rotation and policy enforcement for all types of users.

In SC-900 (Microsoft Security, Compliance, and Identity Fundamentals), the user is central to understanding identity concepts. The exam covers how users are created, managed, and authenticated in Microsoft Entra ID. It also covers the difference between cloud-only users and synchronized users, how guest users (B2B collaboration) work, and how user attributes affect security policies. The exam emphasizes that a user must be properly identified before any security controls can be applied.

## Real-life example

Imagine you live in an apartment building with a security door at the main entrance. Each resident has a key fob that opens the front door. In this everyday scenario, each resident is a user of the building. The key fob is their credential. When you get a new roommate, the building manager creates a new key fob specially programmed for them. This is like provisioning a new user account in Active Directory. When you lose your key fob, the manager deactivates it and issues a new one. That is exactly what happens when a user forgets their password and gets a reset.

Now think about the delivery driver who comes to drop off a package. The driver does not have a key fob, but they press a buzzer and you let them in from your apartment. In IT, this is like a guest user who authenticates through a different mechanism, such as a temporary access pass or a B2B collaboration invitation.

Finally, consider the cleaning crew. They have a master key that opens all doors but only during certain hours. In the IT world, this is a privileged user or an admin account. The master key is like an admin role in Azure that grants access to multiple resources.

In this analogy, the building's access control system tracks who enters and when. That is auditing. If the manager finds that the cleaning crew entered at midnight when they were not scheduled, it raises a red flag. Similarly, in IT, user activity logs help detect anomalies. The manager also reviews the list of active keys every month and deactivates keys for residents who have moved out. This is an access review or recertification process.

This entire system, from key issuance to revocation to monitoring, is built on the basic concept of a user. Without a clear definition of who is a user, the building would be insecure. In IT, the same principle applies. Every system, application, and service must know who the user is to make decisions about security, compliance, and service delivery.

## Why it matters

The concept of a user is fundamental to almost every aspect of IT. Without a clear definition of who or what is using a system, there is no way to enforce security, provide personalized services, or track accountability. In cybersecurity, the user is the frontier. Attacks often start by compromising a user account, either through phishing, credential stuffing, or social engineering. Therefore, managing users properly is the first line of defense.

In identity and governance, user management is not just about creating accounts. It involves the entire lifecycle from hire to retire. When an employee joins the company, their user account must be created quickly but securely. Roles and groups must be assigned to give them access to the tools they need. When they change roles, their access must be updated. When they leave, all access must be revoked immediately. Failure in any of these steps can lead to security breaches or compliance violations.

In service management, understanding who the user is helps IT teams prioritize and triage. A VIP user having a problem might be handled differently than a standard user. Knowing the user's role and location helps in diagnosing issues. For example, if a user in a remote office reports a slow application, the IT team can check if their site has connectivity issues. If a user in the finance department reports a problem with the billing system, it might be a critical issue with high business impact.

In cloud environments like Azure, users are the basis for RBAC. Without users, you cannot delegate administration. You cannot give a developer access to only one resource group. You cannot grant a support team read-only access to logs. The entire Azure governance model depends on well-defined users and groups.

in compliance-driven industries, auditors want to see who has access to what. They want to know how users are authenticated and whether there are controls for separation of duties. Sarbanes-Oxley (SOX), HIPAA, and GDPR all require strict user access controls. A company that does not manage users properly risks fines, reputational damage, and data breaches.

On exams like ITIL 4, Azure Fundamentals, and SC-900, the term user appears in many contexts. Understanding the nuances (human vs. service user, internal vs. external, guest vs. member) can make the difference between a correct and incorrect answer. The concept is often tested in scenario questions where you must decide how to grant access or how to respond to a request.

the user is the atomic unit of IT security and service management. Every policy, every permission, every audit trail ultimately traces back to a user. Getting user management right is non-negotiable for a secure and efficient IT environment.

## Why it matters in exams

The term "user" is pervasive across all three related exams: ITIL 4, Azure Fundamentals (AZ-900), and SC-900. While the concept seems simple, exam questions test your understanding of the specific definitions and contexts used in each certification.

For ITIL 4, the term "user" is distinguished from "customer" and "stakeholder." According to ITIL, a user is someone who actually uses the service in their daily work. They may not be the one paying for it (the customer). This nuance is crucial in service level management and incident management questions. For example, an exam question might describe a situation where a user reports an incident, but the customer wants a different resolution timeframe. You need to know that the incident response is based on the user's need, but the service level agreement is with the customer.

In ITIL 4 Foundation exams, there are questions about the service value chain and how users interact with it. You might be asked which practice (such as service desk or incident management) directly interacts with users. Understanding that the user is the primary contact point for operational issues helps answer such questions correctly.

For Azure Fundamentals (AZ-900), the term user is tested in the context of identity services. You need to know that Azure AD (now Microsoft Entra ID) is the identity provider for users. Questions may ask about the difference between an Azure AD user and a subscription administrator. For example, an Azure AD user can be assigned roles within the directory, but a subscription administrator has owner-level access to Azure resources. There are also questions about user account types: cloud-only vs. synchronized from on-premises Active Directory. The exam expects you to know that synchronized users come from a source of authority (on-premises AD) and cannot be managed in the cloud directly.

For SC-900 (Microsoft Security, Compliance, and Identity Fundamentals), users are a central topic. The exam covers user identity in depth: how users are created (via Azure portal, PowerShell, or synchronization), how they are authenticated (multifactor authentication, passwordless), and how they are managed (lifecycle workflows, access reviews). You must know the difference between a user, a guest user (B2B collaboration), and a service principal. Questions often ask about the proper way to invite an external collaborator or how to restrict a user's access based on conditions (Conditional Access).

SC-900 also covers user permissions in Microsoft 365 environments. You might be asked about role-based access control versus administrative units. Knowing that a user can be assigned a role that scopes to a specific set of users (like help desk for only finance team members) is important.

In all three exams, scenario-based questions are common. You will be asked what to do when a user leaves the company (deprovisioning), what happens when a user is assigned a role, or how to verify a user's identity. These questions require you to apply the concept of user to real IT scenarios.

Because the term is foundational, many questions from other domains depend on understanding users. For example, resource management in Azure, incident management in ITIL, and security policies in SC-900 all require knowing who the user is. If you misunderstand the definition of user in these specific contexts, you will likely get follow-up questions wrong as well. Therefore, it is essential to study the user concept as it appears in each exam's official syllabus and recognize the subtle differences in terminology.

## How it appears in exam questions

The term "user" appears in exam questions in several distinct patterns. Recognizing these patterns helps you identify the correct answer faster.

Scenario-based questions: These describe a situation where a person needs access to a resource. For example, "A new employee, Jane, joins the sales team. She needs access to the CRM application and a shared mailbox. What should the administrator do?" The answer typically involves creating a user account, assigning licenses, and adding the user to appropriate security groups. In SC-900, the scenario might involve inviting an external partner as a guest user. You need to know that the invite sends an email, and the guest user signs in with their own credentials.

Configuration questions: These ask how to set up something for a specific type of user. For instance, "You need to ensure that users accessing the finance application from outside the corporate network must use multi-factor authentication. Which policy should you configure?" The answer is a Conditional Access policy targeting all users or a specific group of users. In AZ-900, you might be asked how to assign an Azure role to a user. The correct process is to go to the subscription, select Access control (IAM), and then add role assignment.

Troubleshooting questions: These present a problem and ask you to identify the cause. For example, "A user cannot access the company portal even though they input the correct password. All other users can access it. What is the most likely cause?" The answer might be that the user account is disabled, locked, or not synchronized properly. In ITIL 4, a troubleshooting question might be: "A user reports that they cannot log into the ERP system. The service desk verifies that the user's credentials are correct. What should be the next step?" The answer is to check the user's role permissions or escalate to the application support team.

Definitional questions: These ask straightforward definitions. For example, "Which ITIL term describes a person who uses a service on a daily basis?" The answer is "user." Or, "In Microsoft Entra ID, what is the difference between a member user and a guest user?" The correct answer involves the authentication source and directory rights.

Best practice questions: These ask about proper procedures. For example, "What is the recommended practice for managing a user account when an employee leaves the organization?" The answer includes disabling the account, revoking session tokens, and removing group memberships. In ITIL 4, a best practice question might be: "The service desk should maintain a record of which user requested which service. Why?" The answer involves accountability and auditability.

Comparison questions: These ask to identify the correct statement about users. For example, "Which of the following is true about Azure AD users?" Options might include: users can be cloud-only, users cannot be deleted from the recycle bin, or all users must have MFA enabled. You need to know that cloud-only users exist only in Azure AD and that deleted users can be restored within 30 days.

Understanding these question patterns will help you approach the exams with confidence. Always read each question carefully to identify whether the user is a person, a service principal, or an external guest. The answer choices often hinge on these distinctions.

## Example scenario

You are an IT support specialist for a mid-sized company called GreenLeaf Inc. The company uses Microsoft 365 and Azure for its operations. One morning, the HR director calls you: two new marketing assistants, Alice and Bob, are starting today. You need to set up their accounts.

First, you open the Microsoft 365 admin center. You click on Users, then Active users, and then Add a user. For Alice, you enter her first name, last name, and display name. You set her username as alice@greenleaf.com. For this example, you choose to auto-generate a password that Alice will change at first login. You assign her the Microsoft 365 Business Basic license, which gives her access to email, Teams, and SharePoint. During the setup, you also add her to the Marketing security group. This group has permissions to the marketing shared folder and the marketing team site.

Next, you repeat the same steps for Bob. However, Bob will be working remotely and will need access to the internal expense reporting application, which is hosted in Azure. To grant that access, you go to the Azure portal, find the expense app's enterprise application, and under Users and groups, you add Bob. You assign him the "User" role within that application, which gives him read and submit permissions but not approval rights.

Now, Bob calls you because he cannot log into the expense app. You check his account. You see that his account is enabled, his password is correct, but he is not listed in the application's users list. You realize that you forgot to assign him to the enterprise application in Azure. You fix it by adding him, and he successfully logs in.

Later, Alice reports that she cannot access a shared document in the marketing team site. You check the SharePoint site permissions. You see that the Marketing group has edit permissions, and Alice is in that group. You suspect that the permissions might not have propagated yet. After a few minutes, she tries again and it works. This is because Azure AD group membership updates can take a few minutes to sync to SharePoint.

This scenario shows the practical steps of user provisioning, group membership, application assignment, and troubleshooting. It highlights the different places where user access is managed: Microsoft 365 admin center for core services, Azure portal for cloud applications, and SharePoint for document permissions. The user concept ties all these together. Without proper user setup, Alice and Bob would not be able to do their jobs effectively.

As an IT professional, you would also follow up with an access review after 30 days to ensure that Alice and Bob still need all the permissions they received. You might also automate future onboarding using Azure AD lifecycle workflows to create users from HR system data automatically. This scenario is exactly the type of practical situation you might encounter on the job or in an exam question.

## Common mistakes

- **Mistake:** Thinking that every user in an IT system is a human being.
  - Why it is wrong: In modern IT environments, many 'users' are automated services, applications, or devices. These are represented as service principals or system accounts. Treating them as human users can lead to misconfigured permissions or security gaps because service accounts often need different management, such as long-lived passwords or certificate-based authentication.
  - Fix: Always check the context. If the question mentions a 'user' that runs a scheduled task or an API call, it is likely a service principal or managed identity, not a person.
- **Mistake:** Confusing the ITIL definitions of 'user' and 'customer'.
  - Why it is wrong: In ITIL 4, a user is someone who uses the service operationally, while the customer is the person who pays for or authorizes the service. In exam scenarios, if you treat a user as the customer, you might choose the wrong service management process or incorrectly define who has authority to change service levels.
  - Fix: Memorize: user = daily operator of the service; customer = person who holds the budget or signs the contract. In incident management, the user reports the problem; the customer is informed of service level breaches.
- **Mistake:** Assuming that removing a user from Azure AD automatically removes all resource access immediately.
  - Why it is wrong: When a user is deleted from Azure AD, access to Azure resources (like VMs, storage, databases) is revoked fairly quickly, but access to Microsoft 365 services like SharePoint and Exchange may still have cached tokens that can work for up to an hour. Also, if the user was synchronized from on-premises AD, deleting them in the cloud does not delete them on-premises, and they may be re-created.
  - Fix: Always disable the user account first, then revoke sessions and tokens. For synchronized users, block sign-in in the cloud and disable the on-premises account. Allow time for replication and token expiration.
- **Mistake:** Believing that a guest user in Microsoft Entra ID has the same permissions as a member user by default.
  - Why it is wrong: Guest users have limited directory permissions by default. They can read their own profile but cannot enumerate the full directory. Many applications require explicit configuration to allow guest access. An exam question might trick you into thinking guests automatically see everything.
  - Fix: Know that guest users have restricted directory access. To grant more permissions, an administrator must explicitly assign roles or add them to the directory readers role.
- **Mistake:** Forgetting that user accounts can be locked due to multiple failed login attempts, and the lockout policy varies by organization.
  - Why it is wrong: In troubleshooting questions, giving up on the account as 'disabled' when it is actually 'locked out' is a common error. Locked accounts can be unlocked without resetting the password. Misdiagnosing can lead to unnecessary password resets or escalation.
  - Fix: When a user cannot log in, always check if the account is enabled, not expired, and not locked. The lockout status is visible in Active Directory or Azure AD sign-in logs.

## Exam trap

{"trap":"The question states: 'A user reports they forgot their password and cannot log in. What should the IT administrator do first?' An option is 'Reset the user's password in Azure AD.' Another option is 'Unblock the user's account.'","why_learners_choose_it":"Learners often choose 'reset password' immediately because that is the standard remedy for forgotten passwords. The word 'forgot' suggests password reset is the correct action. However, the actual problem might be that the account is locked out due to multiple attempts, not that the password is forgotten.","how_to_avoid_it":"Read the question carefully. If the user explicitly says they forgot the password, then a reset is appropriate. But if the scenario describes multiple failed attempts or a locked account, the first step is to unlock the account. In Azure AD, unlocking does not require password reset. Always differentiate between authentication failure due to lockout versus forgotten credentials."}

## Commonly confused with

- **User vs Customer (ITIL):** In ITIL 4, a user is someone who actually uses the service, while a customer is the person or organization that purchases or authorizes the service. A user might report an incident directly, but the customer is the one who holds the service level agreement. For example, a company's finance department employees are users of the ERP system, but the CFO is the customer who pays for it and sets the service expectations. (Example: Sarah is a user of the email service because she sends and receives emails daily. Her manager, who approves the email service budget, is the customer.)
- **User vs Service Principal:** A service principal is an identity created for use by applications, automated tools, and services to access specific Azure resources. Unlike a human user, a service principal does not have a password that a person types; it uses client secrets or certificates. In Azure AD, a service principal is the application's representation in a tenant, and it is used for authentication where no human is present. (Example: A backup application running on a server uses a service principal to authenticate to Azure storage. The application is the user, but it is not a person; it is an automated process.)
- **User vs Managed Identity:** A managed identity is a special type of service principal automatically managed by Azure. It is used for Azure resources like VMs or Azure Functions to authenticate to other Azure services without storing credentials. Unlike a regular user or service principal, you do not create or manage the credentials; Azure handles them automatically. It is simpler and more secure for Azure resource-to-resource authentication. (Example: A virtual machine running a custom application needs to access an Azure Key Vault. You enable a system-assigned managed identity on the VM, and that identity becomes the user that can be granted access to the Key Vault.)

## Step-by-step breakdown

1. **Identification of the user** — The first step is to determine who or what the user is. For human users, this means collecting identity data such as full name, job title, department, and manager. For non-human users (service principals), you identify the application or service that needs access. This step is crucial because it determines the type of user object to create and the appropriate authentication method.
2. **Creation of the user identity** — An administrator creates a user object in the identity directory. In Microsoft Entra ID, this can be done through the Azure portal, Microsoft 365 admin center, PowerShell, or automated HR sync. The user object includes attributes like userPrincipalName (UPN), display name, and password or other credentials. For service principals, you register an application and create the service principal object.
3. **Authentication setup** — The user must have a method to prove their identity. For human users, this could be a password (with or without multi-factor authentication), biometrics, or passwordless methods. For service principals, authentication is done via client secrets or certificate thumbprints. The administrator configures the authentication policies, such as requiring MFA or blocking legacy authentication.
4. **Authorization assignment** — Once the user can authenticate, they need permissions to access resources. This is done by assigning roles (RBAC), adding the user to security groups, or granting application-specific permissions. For example, in Azure, you assign a role like 'Contributor' on a subscription. In ITIL, the user might be added to a service support group to receive incident notifications.
5. **Provisioning of access** — Access is provisioned to applications, data, and services. This might involve assigning licenses in Microsoft 365, adding the user to SharePoint site memberships, or configuring access to on-premises resources through group membership. In modern environments, this is often automated using identity lifecycle management tools that trigger when the user is created.
6. **Monitoring and enforcement** — After the user has access, the system should monitor for unusual activity. Suspicious sign-ins may trigger conditional access policies that require additional authentication or block access. Auditing logs capture user actions for compliance. The administrator periodically reviews access rights and adjusts them.
7. **Deprovisioning** — When the user no longer needs access (e.g., employee leaves, project ends, or service is decommissioned), the account must be disabled or deleted. This involves revoking sessions, removing group memberships, and reclaiming licenses. For service principals, you rotate secrets or delete the service principal entirely. This step prevents orphaned accounts that could be exploited.

## Practical mini-lesson

Let us walk through a practical scenario involving a user in a hybrid environment. Your company has on-premises Active Directory (AD) and uses Microsoft Entra ID for cloud services via Azure AD Connect. You are the identity administrator. A new employee, Maria, is hired in the engineering department. The HR system automatically creates a user account in on-premises AD. Azure AD Connect synchronizes that account to Microsoft Entra ID. This is example of a synchronized user. The synchronization occurs every 30 minutes by default, so there is a slight delay between creating the account on-premises and its availability in the cloud.

Once the user object is in Microsoft Entra ID, Maria can be assigned cloud resources. You assign her a Microsoft 365 E3 license, which gives her Exchange Online, SharePoint Online, and Teams. You also add her to the Engineering security group, which is synchronized from on-premises AD. This group grants access to the engineering SharePoint site and the engineering team in Teams.

However, Maria also needs access to an Azure virtual machine for testing. You cannot use the on-premises group directly for Azure RBAC because Azure AD groups are needed for Azure role assignments. So you create an Azure AD security group called 'EngineeringAzureAccess' and assign it the 'Virtual Machine Contributor' role on the engineering resource group. You then add Maria to that Azure AD group. This is an important distinction: on-premises groups sync to Azure AD but you can also create groups directly in Azure AD for cloud-only roles.

Now, Maria tries to log into the Azure portal. She uses her on-premises credentials (her domain username and password) because password hash synchronization is enabled. She passes authentication against Microsoft Entra ID. She sees the virtual machines in the resource group. This works because her user object has the necessary role via group membership.

A common issue arises: Maria's account in on-premises AD is disabled (perhaps she forgets to log out and someone disables it for security). The next sync cycle, the disabled status flows to Microsoft Entra ID, and Maria cannot log into Azure or Microsoft 365. The administrator must enable the on-premises account and wait for the sync. Alternatively, the administrator can temporarily block sign-in in Microsoft Entra ID directly, but that only affects cloud access; the on-premises status should remain enabled for the sync to function correctly.

What can go wrong? If the synchronization fails, new users might not appear for hours. If the UPN (user principal name) is changed on-premises but not in the cloud, sign-in fails. If the user object in Azure AD is deleted accidentally, but the on-premises account still exists, the next sync will recreate the cloud object (if it was soft-deleted and not permanently removed).

As a professional, you must understand these mechanics. You need to know how to force a sync (Start-ADSyncSyncCycle -PolicyType Delta) for urgent user creation or password resets. You need to know how to troubleshoot sync errors using the Azure AD Connect Health dashboard. You should also understand the difference between cloud-only users (created directly in Azure AD, not synced) and synchronized users, as this affects password policies, self-service password reset, and management responsibilities.

In governance, you should ensure that duplicate user accounts are not created. For example, if HR creates a user with a misspelled email and then corrects it, the old account might still exist. An identity cleanup project might be needed. Also, service accounts for applications should be managed separately. They should not be disabled automatically by the same HR-driven lifecycle because they may not have a counterpart in the HR system.

This practical lesson shows that managing users is not just about clicking 'add user.' It involves understanding the underlying sync principles, group management, role assignment, and troubleshooting. In an exam, you might be asked to explain why a user appears or does not appear in a certain service. You now know to check the sync status, group membership, and license assignment.

## Memory tip

Think of the user as the 'who' in the Who, What, Where of IT security: Who is the user (identity), What can they access (permissions), Where are they allowed from (location policy).

## FAQ

**What is the difference between a user and a group in IT identity management?**

A user is a single identity representing a person or service. A group is a collection of users. Assigning permissions to a group is more efficient than assigning them to each user individually. When a user is added to a group, they inherit the group's permissions.

**Can a user be a computer or a device?**

Yes, in many systems, a device can be considered a user when it authenticates to a network. For example, a laptop joined to Active Directory has a computer account. However, in cloud identity platforms like Microsoft Entra ID, devices are separate identity types and are not called users, though they can be managed similarly.

**How often should user access be reviewed?**

Industry best practice and many compliance frameworks (like SOX) require access reviews at least quarterly. For highly sensitive systems, monthly reviews are recommended. Microsoft Entra ID Access Reviews can automate this process.

**What happens when a user's job role changes?**

The IT team should update the user's group memberships and role assignments to match the new role's requirements. This might involve removing old permissions (cleanup) and granting new ones. Automated tools can help trigger these changes based on HR data.

**What is the fastest way to revoke a user's access in an emergency?**

Disable the user account immediately. In Microsoft Entra ID, you can block sign-in. In on-premises AD, disable the account. Then revoke all active sessions and tokens. For Azure resources, remove all role assignments directly after disabling the account.

**What is a 'guest user' in Microsoft Entra ID?**

A guest user is an external user who is invited to collaborate in your Azure AD tenant. They sign in with their own credentials from their home organization or a personal account. Guests have limited directory permissions and are commonly used for B2B collaboration.

## Summary

The term 'user' is one of the most fundamental concepts in IT, appearing across identity management, service management, and cloud administration. In its simplest form, a user is any entity that interacts with a system, whether a person, a device, or an automated service. However, the nuance of the term varies significantly across different contexts. In ITIL 4, the distinction between a user and a customer is critical for understanding service value and incident management. In Azure Fundamentals, the focus is on the user as an identity object within Microsoft Entra ID, with differences between cloud-only and synchronized users. In SC-900, the user is central to security, with emphasis on authentication methods, guest users, and conditional access.

For learners preparing for these exams, mastering the concept means understanding not just the definition but also the real-world implications. You need to know how to create, manage, and deprovision users. You must be able to troubleshoot common issues like account lockouts, sync failures, and permission errors. The exam traps often revolve around confusing user types (human vs. service principal, guest vs. member) or misapplying ITIL terminology.

The key takeaway is that the user is the starting point for almost every IT process. Without a properly identified and authorized user, no system can function securely or efficiently. On the exams, when you see the word 'user,' immediately ask yourself: Is this a person, a service, or a device? Is this a member or a guest? Is this the ITIL definition or the identity management definition? Answering those questions will guide you to the correct response. Study the real-world examples and practice with scenarios to solidify your understanding. The user concept may seem simple, but its correct application is what separates a passing score from a failing one.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/user