Secure identity and access

In Azure AD Conditional Access policies, the Grant control determines the access permissions and authentication requirements that must be satisfied before granting access to resources.

This is the correct answer because Grant controls are the gatekeepers that decide whether to allow or block access, and what additional requirements must be met. These controls include options such as:
- Requiring multi-factor authentication (MFA)
- Requiring device to be marked as compliant
- Requiring Hybrid Azure AD joined device
- Requiring approved client app
- Requiring app protection policy
- Requiring password change

Grant controls are applied at the point of access decision, before the user is granted entry to the resource. They enforce the security requirements that must be fulfilled as a condition for access.

The other answers are incorrect for the following reasons:

The option about specific Azure resources and applications being included in policy scope refers to the 'Assignments' section of Conditional Access policies, not the Grant controls. This is where you define which users, groups, cloud apps, and conditions the policy applies to.

The option mentioning access permissions and session limitations after authentication refers to 'Session controls' rather than Grant controls. Session controls manage what happens during an active session after access has been granted, such as enforcing app-enforced restrictions, using Conditional Access App Control, or setting sign-in frequency.

The option about network locations and IP address ranges refers to 'Conditions' in Conditional Access policies, specifically the 'Locations' condition. These are factors that determine when the policy is evaluated, not what happens when access is being granted.

The primary difference between delegated permissions and application permissions in OAuth 2.0 consent grants for Azure AD enterprise applications centers on the context in which the application operates:

Correct Answer:
Delegated permissions operate within the context of a signed-in user and are limited by that user's privileges, while application permissions grant the app access to resources based on its own identity.

This is accurate because:
- Delegated permissions require a user to be signed in. The application acts on behalf of the user and can only access what that user has permission to access. The effective permissions are the intersection of what the app is granted and what the user can do.
- Application permissions (also called app-only permissions) allow the application to access resources using its own identity, without a signed-in user present. These are typically used for background services, daemons, or automated processes.

Why Other Answers Are Incorrect:

The second option incorrectly reverses the scope characteristics. It suggests delegated permissions provide directory-level access while application permissions are restricted to user-owned resources. In reality, application permissions often provide broader, tenant-wide access, while delegated permissions are constrained by the signed-in user's privileges.

The third option inverts the definitions entirely. It states that delegated permissions allow apps to act as themselves using service principal identity, when this actually describes application permissions. It also incorrectly claims application permissions require an interactive user session, when they specifically do NOT require user interaction.

The fourth option mischaracterizes both permission types. It suggests delegated permissions grant tenant-wide access across all resources, which is incorrect - they are limited by user context. While it correctly notes application permissions can be constrained to specific resource sets, the overall characterization is backwards and misleading.

The correct answer is: System-assigned and user-assigned managed identities.

Microsoft Azure provides exactly two types of managed identities:

1. System-assigned managed identities: These are created as part of an Azure resource (like a VM, App Service, or Function App). The lifecycle is tied directly to the resource - when the resource is deleted, the identity is automatically deleted. Each resource can have only one system-assigned managed identity, and it cannot be shared across multiple resources.

2. User-assigned managed identities: These are created as standalone Azure resources. They have an independent lifecycle from the resources that use them. A single user-assigned managed identity can be associated with multiple Azure resources, and it persists even when the resources using it are deleted.

Why the other options are incorrect:

The option mentioning 'resource-assigned managed identities' uses incorrect terminology. Azure does not have a managed identity type called 'resource-assigned.' While system-assigned identities are tied to resources, they are not called 'resource-assigned.'

The option suggesting 'application-assigned and user-assigned managed identities' is incorrect because 'application-assigned' is not a valid type of managed identity in Azure. Although managed identities can be used by applications, there is no specific managed identity type with this name.

The option mentioning 'tenant-assigned managed identities for cross-subscription access' introduces terminology that doesn't exist in Azure's managed identity framework. While managed identities can be used across subscriptions in certain scenarios, there is no managed identity type called 'tenant-assigned.' Cross-subscription access is a capability, not a managed identity type.