Free Practice Questions for Microsoft SC-300 Exam

In Windows 10, Windows Hello for Business replaces passwords with strong two-factor authentication on PCs and mobile devices. This authentication consists of a new type of user credential that is tied to a device and uses a biometric or PIN.

After an initial two-step verification of the user during enrollment, Windows Hello is set up on the user's device and Windows asks the user to set a gesture, which can be a biometric, such as a fingerprint, or a PIN. The user provides the gesture to verify their identity. Windows then uses Windows Hello to authenticate users.

Statement

Answer

1. Before Admin1 can perform a task that requires the User Administrator role, an approver must approve the activation request.

Yes

2. Admin2 can request activation of the User Administrator role for a period of two hours.

No

3. If Admin3 connects to the Azure Active Directory admin center, and then activates the User Administrator role, Admin3 will be prompted to authenticate by using multi-factor authentication (MFA) twice.

Based on Microsoft’s SC-300 Identity and Access Administrator Study Guide, Microsoft Learn module “Manage Azure AD roles by using Privileged Identity Management (PIM)”, and Exam Ref SC-300, the following logic applies:

Approval requirement (Admin1) — In the Role setting details image, Require approval to activate is set to Yes, and one approver is listed. This means before any user (e.g., Admin1) can activate the User Administrator role, approval must be granted. Therefore, Admin1 must have the activation request approved before performing any User Administrator tasks. ✅ (Yes)

Activation duration (Admin2) — The configuration shows Activation maximum duration (hours): 8 hours. This defines the maximum allowed time a user can remain active after role activation. Admin2 can activate for up to 8 hours, not 2 hours unless specifically limited during activation. Hence, the statement claiming Admin2 can activate for “two hours” is incorrect. ❌ (No)

MFA enforcement (Admin3) — Two relevant controls exist:

Conditional Access policy requiring MFA for all users.

PIM role setting On activation, require Azure MFA = Yes.

According to Microsoft documentation, when both Conditional Access and PIM MFA enforcement apply, Azure AD intelligently avoids redundant prompts by honoring a single valid MFA session token. This means Admin3 would only be prompted once for MFA, even though both mechanisms require it. ❌ (No)

Therefore, as verified by official Microsoft materials and SC-300 documentation:

By default, only Global Administrators and Identity Governance Administrators can create catalogs in Azure AD Entitlement Management. To delegate this ability to other users such as User1, you must modify the Entitlement Management Settings in the Identity Governance blade.

Microsoft documentation and the SC-300 exam guide note:

“In the Entitlement management settings, you can configure who can create new catalogs and manage catalog ownership.”

Therefore, granting User1 the permission to create catalogs and add resources requires configuring entitlement management settings—not changing role assignments in the Roles and administrators blade.

The question asks which role allows a user to create access reviews for Azure AD roles using the principle of least privilege.

Privileged Role Administrator can manage all role assignments and access reviews, but it has more privileges than needed.

Identity Governance Administrator manages entitlement management and access packages, not Azure AD roles directly.

User Administrator can manage users but not access reviews for roles.

✅ User Access Administrator is the correct least-privilege role, as it allows management of access reviews related to Azure AD roles and role-assignable groups.

From Microsoft Documentation (SC-300 Exam Guide):

“The User Access Administrator role allows management of access reviews and permissions for Azure AD roles and resources using the least-privileged approach.”

According to the Microsoft Identity and Access Administrator (SC-300) Official Study Guide and Microsoft Learn documentation on Azure AD roles and permissions, the Cloud Application Administrator role provides privileges to manage applications while enforcing the principle of least privilege.

The scenario requires:

Preventing User1 from being added as an owner of newly registered apps.

Allowing User1 to manage Application Proxy settings (used for publishing on-premises apps through Azure AD).

Allowing User2 to register new applications.

Application Administrator: Can create and manage all app registrations and enterprise apps, and can add owners — too permissive for this requirement.

Cloud Application Administrator: Can manage applications, including Application Proxy settings, but cannot assign application owners or grant broad permissions.

Application Developer: Can only register and manage own applications.

Service Support Administrator: Provides service health access — not relevant here.

Thus, to let User1 manage Application Proxy and prevent assigning ownership of new apps, Cloud Application Administrator is the correct and least-privileged choice.

 VM1: Managed1 and Managed2 only

 App1: A system-assigned managed identity and Managed2 only

Questions no: 269

Verified Answer:

VM1: Managed1 and Managed2 only

App1: A system-assigned managed identity and Managed2 only

Comprehensive and Detailed Explanation with all Microsoft SC-300: Identity and Access Administrator documents:

To answer this question, we must apply the principles of Managed Identities for Azure resources. Managed identities provide an automatically managed identity in Microsoft Entra ID for applications to use when connecting to resources that support Microsoft Entra authentication (like Azure Key Vault or SQL).

1. Understanding Identity Types:

User Objects (User1): Standard user accounts are used for human sign-ins. You cannot assign a standard user object (like User1) as the identity of an Azure resource (like a VM or App Service). The resource must use a Service Principal or Managed Identity. Therefore, any option including User1 is incorrect.

User-Assigned Managed Identities (Managed1, Managed2): These are standalone Azure resources that can be assigned to one or more Azure resources (like VMs or App Services).

System-Assigned Managed Identities: These are enabled directly on the resource itself and share the resource's lifecycle.

2. Analysis for VM1:

Azure Virtual Machines support User-assigned managed identities.

You can assign multiple user-assigned identities to a single VM.

Looking at the dropdown options for VM1:

Options with User1 are invalid.

This leaves Managed2 only or Managed1 and Managed2 only.

Since both Managed1 and Managed2 are valid user-assigned identities available in the subscription, you can assign both.

Conclusion: Select Managed1 and Managed2 only.

3. Analysis for App1:

Azure App Services support both System-assigned and User-assigned managed identities concurrently.

Looking at the dropdown options for App1:

Options with User1 are invalid.

Managed1 is not listed in the dropdown options (Managed identities must be in the same region as the resource; often this question implies a region mismatch, or simply restricts the choice).

Managed2 is listed as a valid user-assigned option.

A system-assigned managed identity is listed as a valid option.

Since you can configure an App Service to use both its system-assigned identity and a user-assigned identity simultaneously, the most complete correct answer identifies all capable identities.

Conclusion: Select A system-assigned managed identity and Managed2 only.

Reference Extract:

"Managed identities for Azure resources provide Azure services with an automatically managed identity in Azure Active Directory... There are two types of managed identities: System-assigned... and User-assigned... You can assign a user-assigned managed identity to [Azure Virtual Machines and Azure App Service]." (Source: Microsoft Learn - What are managed identities for Azure resources?)

The Conditional Access What If tool is designed to simulate sign-ins under various conditions to test Conditional Access policies without performing real sign-ins. Microsoft’s SC-300 guide specifies that this tool is essential for validating the effect of a policy based on user, location, device, or risk level.

In this case, the administrator wants to test a policy that blocks access when a high-severity sign-in alert (sign-in risk) occurs and when a user signs in from another country. These scenarios are based on risk and location conditions—both supported in the What If tool simulation.

Microsoft Learn: “Use the What If tool to simulate sign-ins and verify whether a specific Conditional Access policy will be applied.”

Box 1: Yes

Invitations can only be sent to outlook.com. Therefore, User1 can accept the invitation and access the application.

Box 2. Yes

Invitations can only be sent to outlook.com. However, User2 has already received and accepted an invitation so User2 can access the application.

Box 3. No

Invitations can only be sent to outlook.com. Therefore, User3 will not receive an invitation.

Based on the Microsoft SC-300: Identity and Access Administrator Study Guide and Microsoft Learn module “Manage external collaboration settings in Azure AD”, Azure Active Directory provides granular control over external collaboration through External collaboration settings and Collaboration restrictions. These settings control which external domains can receive guest invitations.

The configuration in the exhibit shows:

“Allow invitations only to the specified domains (most restrictive)”

Target Domain: Outlook.com

This means invitations can only be sent to users whose email domains are explicitly listed (in this case, Outlook.com). Any other external domain (like fabrikam.com or adatum.com) is not permitted to receive or accept invitations.

User1@outlook.com

Domain Outlook.com is listed under allowed domains.

Although the invitation was initially not accepted, since the domain is allowed, User1 can accept the invitation and gain access.✅ Answer: Yes

User2@fabrikam.com

The domain fabrikam.com is not listed in the allowed domains list.

However, this user already accepted the invitation before the restriction was configured.

Once a guest has accepted the invitation, they are an existing guest object in Azure AD and retain access unless explicitly removed.✅ Answer: Yes

User3@adatum.com

Domain adatum.com is not listed under allowed domains.

Therefore, this user cannot receive or accept new invitations for collaboration resources like SharePoint Online.❌ Answer: No

Summary from Microsoft documentation:

“When collaboration restrictions are set to allow invitations only to specified domains, invitations to all other domains are blocked. Existing guest users who have already accepted invitations remain unaffected.”

(Source: Microsoft Learn – Configure external collaboration settings in Azure AD)