Unit 2 - Practice Quiz

Authentication is the process of proving you are who you say you are, typically with a username and password. It answers the question, "Who are you?".

Authorization happens after successful authentication and determines the level of access an authenticated user has. It answers the question, "What are you allowed to do?".

The user's identity was successfully authenticated (they logged in), but they were not authorized (did not have the necessary permissions) to access the specific folder.

The Zero Trust model operates on the principle of assuming a breach. It does not trust any user or device by default, requiring verification for every access request, regardless of its origin.

Least privileged access is a fundamental pillar of Zero Trust. It ensures that users are only granted the specific permissions they need, for the shortest time necessary, to complete a task, minimizing potential security risks.

In all cloud service models (IaaS, PaaS, SaaS), the cloud provider is always responsible for the security of the physical infrastructure, such as datacenters, servers, and networking hardware.

MFA adds a critical layer of security by requiring two or more verification methods to prove a user's identity, significantly reducing the risk of unauthorized access from compromised credentials.

Microsoft Entra ID (formerly Azure Active Directory) is Microsoft's multi-tenant, cloud-based directory and identity management service. It provides user authentication, single sign-on (SSO), and access management for various applications.

Single Sign-On (SSO) is a key feature of Microsoft Entra ID that allows users to authenticate once and gain access to multiple different applications and resources without needing to re-enter their credentials.

A common hybrid scenario involves using Microsoft Entra Connect to synchronize user identities from a traditional on-premises Windows Server Active Directory to the cloud-based Microsoft Entra ID.

Groups allow administrators to grant access rights and permissions to a collection of users at once. Managing group membership is far more efficient than assigning permissions to each individual user.

Dynamic groups use rules based on user or device attributes to automatically add or remove members. This reduces administrative overhead as membership is kept up-to-date without manual intervention.

Guest users are B2B (business-to-business) collaboration accounts. They are for external users that you invite to your tenant to grant them access to specific apps or resources.

RBAC stands for Role-Based Access Control, a system for managing access to resources based on the roles of individual users within an organization.

A role assignment in Azure connects three elements: a Security Principal (who gets access - user, group), a Role Definition (what they can do - e.g., 'Reader'), and a Scope (what resources the access applies to - e.g., a specific resource group).

The Reader role provides read-only access to Azure resources. Users with this role can view everything but cannot create, update, or delete resources.

Scope defines the boundary for the role assignment. It can be a management group, a subscription, a resource group, or an individual resource. Permissions are inherited by lower-level scopes.

Conditional Access policies are if-then statements. If a user meets certain conditions (like signing in from an unfamiliar location), then an access control (like requiring MFA or blocking access) is enforced.

A condition is a signal that is evaluated. Common conditions include the user's location, the device they are using, the application they are accessing, and the real-time sign-in risk. Requiring MFA and blocking access are controls, not conditions.

Identity Governance focuses on visibility and control over the access lifecycle. It includes features like access reviews, privileged identity management, and entitlement management to ensure access is appropriate and removed when no longer needed.

Authentication is the process of verifying a user's identity, which was successful when the user logged in with their credentials and MFA. Authorisation is the process of determining what an authenticated user is allowed to do. The "Access Denied" message indicates that the user's identity was verified, but they do not have the necessary permissions (authorisation) to perform the delete action.

The "assume breach" principle means you operate as if an attacker is already inside your network. Micro-segmentation and encrypting internal traffic limit an attacker's ability to move laterally and eavesdrop on communications, which directly addresses this principle. A strong perimeter, password policies, and admin rights are security measures, but they don't directly reflect the operational mindset of assuming a breach has already occurred.

To meet the specific requirement, the policy must be targeted correctly. The 'Users' assignment should be scoped to 'All guest and external users'. The 'Cloud apps' assignment must target the specific 'ProjectPhoenix' application. Finally, the 'Grant' control must be set to 'Require multi-factor authentication'. The other options either target the wrong users, the wrong apps, or apply the wrong controls.

The Virtual Machine Contributor role provides permissions to manage virtual machines (including restarting them) but does not include permissions to manage the virtual network or storage accounts they connect to. Assigning this role at the specific resource group scope (dev-rg) ensures the developer's permissions are limited only to the resources they need to manage, perfectly aligning with the principle of least privilege. Contributor and Owner are too broad, and Virtual Machine User Login only allows logging into the VM, not managing it.

Entitlement Management is designed to manage identity and access lifecycle at scale. Access Packages are bundles of resources that users can request. They can be configured with approval workflows, such as requiring manager approval, which perfectly fits this requirement. Access Reviews are for periodic re-certification of access, PIM is for managing privileged roles, and Conditional Access is for enforcing access policies at the time of sign-in.

Dynamic groups in Microsoft Entra ID automatically manage membership based on rules that query user or device attributes. To automatically populate a group based on the 'department' attribute, you must create a group with a 'Dynamic User' membership type and configure a rule such as user.department -eq "Sales". 'Assigned' membership requires manual addition and removal of members.

Microsoft Entra Connect is the tool designed to meet hybrid identity goals. Its synchronization service (Entra Connect Sync) is responsible for creating users, groups, and other objects in Microsoft Entra ID based on the on-premises Active Directory. It also synchronizes password hashes to enable seamless sign-on. While AD FS can be used for federation, Entra Connect is the core tool for synchronization.

Just-in-time (JIT) access ensures that users only have elevated permissions for a limited time when they are actively needed. This is a direct implementation of the principle of least privileged access, as it removes standing, persistent access that could be exploited. While it relates to other pillars, its primary function is to minimize privilege.

Azure RBAC permissions are additive. When multiple role assignments are made, the permissions are the sum of those assignments. The assignment at a child scope (the resource group) grants additional permissions that are not denied by the parent scope (the subscription). Therefore, the user will have Reader permissions on all resources in the subscription and Contributor permissions on the specific resources within that resource group.

Microsoft Entra ID Protection is a feature that uses machine learning and heuristics to detect identity-based risks. One of its key capabilities is detecting impossible travel, where a user signs in from geographically distant locations in a short period. It can then be configured to automatically trigger a response, such as forcing a password reset or requiring MFA.

In the OAuth 2.0 flow, the initial sign-in handles authentication. The resulting access token represents authorisation. It is presented to the API (the resource server) with each request to prove that the application has been granted specific permissions (scopes) to act on behalf of the authenticated user. The API validates the token to decide if the requested action is allowed.

Access Reviews are the designated tool for managing and recertifying access to resources and roles. You can create an access review specifically for a privileged role like Global Administrator, set a recurring schedule (e.g., monthly), and assign a specific person (the CISO) to perform the review and approve or deny continued access. This directly fulfills the policy requirement.

While it seems there should be a simpler way, Microsoft Entra ID does not have a native setting for a default usage location for all new users. Dynamic groups assign members based on attributes; they don't set attributes. Azure Policy primarily governs Azure resources, not Entra ID user properties directly. Therefore, the most common and reliable method to automate this is to use a PowerShell script (often run as an Azure Automation runbook) that periodically finds users without a usage location and sets it to the desired default.

The Website Contributor role is specifically designed for this scenario. It grants permissions to manage the content of web apps (i.e., deploy code) but excludes permissions to manage the App Service Plan itself. App Service Contributor and Contributor are too permissive as they would allow changes to the plan and other settings. Reader would not allow code deployment.

Conditional Access policies allow for fine-grained control. The most efficient way to achieve this is within a single policy. The policy is targeted to 'All users' by default, then the specific executive group is added to the 'Exclude' tab under 'Users and groups'. The 'Conditions' are set to the named locations of the blocked countries, and the 'Grant' control is set to 'Block access'. The exclusion ensures the policy does not apply to the traveling executives.

This is a fundamental concept. The Microsoft Entra ID tenant is the identity and access management service for an organization. An Azure subscription is an agreement with Microsoft to use one or more cloud services, for which charges accrue. An Azure subscription has a trust relationship with exactly one Microsoft Entra ID tenant, which is used to secure and manage access to the resources within that subscription.

Using short-lived tokens forces services to re-authenticate and re-authorize frequently with a central authority. This process of continuous validation aligns directly with the 'Verify explicitly' pillar, which mandates that every access request should be authenticated and authorized. While it also helps with 'Assume breach' (by limiting the window of opportunity for a compromised token), its core function is explicit verification for every session.

Microsoft Entra B2B (Business-to-Business) collaboration is the designed feature for this exact scenario. It allows you to securely share your applications and services with guest users from any other organization, while maintaining control over your own corporate data. The auditors can use their own corporate credentials to sign in, and you can apply security policies and easily revoke their access when the audit is complete. Creating member accounts or using personal accounts reduces security and manageability.

PIM operates on the principle of just-in-time access. Instead of having permanent (standing) permissions, a user is made eligible for a role. To use the role's permissions, they must go through an explicit activation process. This typically involves providing a business justification and/or completing an MFA challenge. The role is then granted for a pre-configured, time-limited period, after which it is automatically revoked.

Azure resource locks are a mechanism to prevent accidental deletion or modification of critical resources. A CanNotDelete lock applies to all users, regardless of their RBAC role, including Owner. To delete the resource group, the lock must first be removed by a user who has permissions to manage locks (such as an Owner).

Azure RBAC has a specific order of evaluation. Deny assignments are evaluated first and take precedence over any Allow assignments (role assignments). Even though the user is part of a group that grants permission to delete blobs, the Deny assignment for the delete action on another group they are a member of will block the operation. Deny assignments are a powerful way to explicitly block access regardless of other roles.

When multiple Conditional Access policies apply to a single sign-in, all grant controls from all matching policies must be satisfied. This acts as a logical AND. In this scenario, the user's sign-in to the Azure Portal matches both Policy A (All users, All cloud apps) and Policy B (High-Privilege Users, Azure Management). Therefore, the user must satisfy both the 'MFA' requirement from Policy A and the 'Compliant or Hybrid Azure AD joined device' requirement from Policy B. Since their device is non-compliant, they cannot satisfy the second requirement, and access is blocked.

The 'Assume Breach' principle of Zero Trust means that you operate as if an attacker has already breached the network perimeter. Therefore, you must protect resources internally. PIM for JIT access minimizes the time window an identity has elevated privileges, reducing the attack surface if the account is compromised. Combining this with Conditional Access that verifies the user's identity (MFA) and device health (compliant device) for every access attempt provides strong, dynamic, risk-based access control, which is central to assuming breach and verifying explicitly.

The 'If reviewers don't respond' setting is critical in automating access governance. When set to 'Take recommendations', the system will automatically apply its own recommendation if the human reviewer fails to act. Since the system recommended 'Deny' for the inactive user Jane, and her manager did not respond, Entra ID will automatically process the 'Deny' recommendation and remove her from the group and any other resources in the access package.

This question tests a core security principle of token-based authorization. An access_token is audience-specific. The aud claim declares the intended recipient (the API) of the token. When a resource server (the custom API in this case) receives a token, one of the first validation steps is to check if the aud claim matches its own identifier. Since the token was issued for the Microsoft Graph API, its aud claim will be for Graph (https://graph.microsoft.com). The custom API will see this mismatch, reject the token as not being intended for it, and return a 401 Unauthorized error.

This question tests the complex syntax and operator precedence of dynamic membership rules. The logic requires grouping the two department checks with an OR. Parentheses are crucial to ensure this OR condition is evaluated first. The result of that is then combined with the jobTitle exclusion using an AND. Option D is incorrect due to operator precedence; without parentheses, the -and would bind more tightly than -or, effectively creating the rule (user.department -eq "Sales") or (user.department -eq "Marketing" and user.jobTitle -notContains "Intern"), which is not the desired logic. Option C is incorrect because -ne is an exact match, while the requirement is to exclude titles containing 'Intern'. Option B uses -and for departments, which is impossible for a single user.

This scenario tests the interaction between RBAC inheritance and Azure Policy. The user's effective permissions on RG1 are an additive combination of inherited and direct assignments, making them a Contributor (since Contributor includes all Reader permissions). Therefore, RBAC allows them to create both resources in RG1. However, Azure Policy is evaluated separately. The Deny policy at the subscription scope specifically blocks VM creation. This policy will block the VM deployment request even though the user has the necessary RBAC permissions. The policy does not mention storage accounts, so that operation is permitted by the user's Contributor role and is not blocked by the policy.

This is the standard and most scalable method for multi-tenant application control. By making the app multi-tenant, it can be provisioned in other tenants. When the partner.com admin grants consent, a service principal for your application is created in their tenant. They can then manage access to this service principal like any other enterprise app, including assigning specific users or groups to it. Setting 'User assignment required?' in your home tenant ensures that access isn't open by default.

Conditional Access policies can be triggered by role activation in Privileged Identity Management (PIM). The 'Require authentication strength' grant control is a powerful feature that goes beyond simply requiring MFA; it dictates the type of MFA allowed. Since the administrator is trying to authenticate for role activation and their available method (Authenticator app push) is not in the list of allowed methods defined by the authentication strength, the grant control condition cannot be met, and access (in this case, the role activation) will be blocked.

This scenario describes the functionality of Conditional Access App Control, which integrates with Microsoft Defender for Cloud Apps (MDCA). When a Conditional Access policy with a session control is triggered, the user's session to the targeted cloud app is routed through a reverse proxy managed by MDCA. This proxy allows for real-time monitoring and control of in-session activities, such as blocking file downloads or uploads, without blocking access to the app itself. This is a key Zero Trust control for preventing data exfiltration.

This question highlights the difference between API permissions and portal usability permissions. While the user has the specific action permission to start the VM, the Azure Portal's user interface needs to read containing resources like resource groups and subscriptions to render the pages and locate the VM. Without at least read permissions on the resource group and subscription (Microsoft.Resources/subscriptions/resourceGroups/read), the user cannot navigate through the portal to find the VM and click the 'Start' button. The API call would likely succeed if made directly via CLI or PowerShell with the full resource ID, but the portal experience would fail.

PIM for Groups works by making a user an active member of the security or Microsoft 365 group for the duration of their activation. When Priya activates her eligible assignment, the PIM service adds her user object to the 'KeyVault-Admins' group's membership list. Because that group is assigned the RBAC role, she inherits the permissions. When the activation expires, the PIM service removes her from the group's membership, thus revoking the inherited permissions. This mechanism allows for JIT access to all resources assigned to that group.

Administrative Units (AUs) are the primary mechanism in Microsoft Entra ID for delegating administrative permissions over a subset of directory objects. You can create an AU containing the users you want the application to manage. Then, instead of assigning a directory role (like Directory Readers) at the tenant level, you assign it to the service principal with the scope of the AU. This effectively grants the User.Read.All permission but limits its application to only the members of that AU, achieving the desired least-privilege access model.

This question requires deep knowledge of OIDC claims. The sub (subject) claim is the primary, stable identifier for the user and must be used for identification. The amr (Authentication Methods References) claim is a JSON array of strings that identify the authentication methods used in the authentication. For example, it might contain ['pwd', 'mfa', 'fido']. The API can inspect this array to confirm that the required FIDO2 method was used. The acr claim is related but refers to the assurance level of the authentication, not the specific method, and nonce is for preventing replay attacks.

Conditional Access token protection, also known as token binding or strict location enforcement, is a feature designed specifically to combat token theft and replay attacks. When enabled, it cryptographically binds the token to the device or browser it was issued to. For location enforcement, it ensures that if a token is stolen and replayed from a different IP address, Microsoft Entra ID will detect the location mismatch and invalidate the session, effectively blocking the attacker. The other options are good security controls but do not directly prevent a stolen token from being replayed from a different location.

B2B direct connect is a feature of External Identities designed for this exact scenario of seamless collaboration between two Entra ID tenants. It creates a mutual, two-way trust that allows users from one tenant to access resources in the other without needing to be represented as guest objects. This provides a much smoother user experience than traditional B2B collaboration, as the user accesses the resource as if it were in their home tenant. Making the apps multi-tenant would work but is less controlled; B2B direct connect allows for granular trust configuration.

This question requires precise knowledge of Azure resource provider actions. The Microsoft.Compute/virtualMachineScaleSets/restart/action permission specifically allows for the restart of all VMs in the scale set (a rolling restart). The .../instances/restart/action is for restarting specific instances, not the whole set. The .../write permission is far too broad and would allow the user to change the scale set's model, which violates the principle of least privilege. performMaintenance is a different operation. Therefore, the single restart/action on the parent resource is the correct, most granular permission for the stated task.

This complex scenario tests the interplay of identity-based security (RBAC) and network-based security for Azure services. For access to be granted, both layers must permit it. The managed identity has the required data-plane RBAC role (Storage Blob Data Reader). The network path is secured via a service endpoint, which allows traffic from the integrated subnet to reach the storage account over the Azure backbone, even when public access is disabled. The managed identity's authentication token is passed within this trusted network traffic. Therefore, both the 'who' (identity) and the 'how' (network) are validated, and the access succeeds.

This is the most complete Zero Trust solution. Zero Trust requires explicit verification for all access, even internal 'east-west' traffic. Microsoft Entra Workload ID allows Kubernetes pods to have their own Entra ID identity, eliminating the need for secrets. They can use this identity to acquire an access token for Azure SQL. Forcing Azure AD authentication on the SQL Database ensures it only accepts these valid, identity-based tokens. Enforcing TLS 1.2 ensures the data is encrypted in transit. This combination verifies the identity of the workload and secures the communication channel, perfectly aligning with the 'verify explicitly' and 'assume breach' principles.

This scenario requires a workflow automation tool that can be triggered by a security alert and can perform complex, conditional actions. Azure Logic Apps is the ideal tool for this. It has a built-in Sentinel connector that can trigger a playbook (a Logic App) when an alert is created. Inside the Logic App, you can parse the alert details (like risk level), then use the Microsoft Graph API connector to check the user's group memberships. Based on this logic, you can then call the Graph API again to disable the user account and revoke their sign-in sessions. This provides the most flexible and powerful way to build the required conditional response.