Free Microsoft SC-300 Practice Test Questions MCQs

Explanation:
Microsoft Entra Private Access (formerly Azure AD Private Access) enables remote users to securely access on-premises applications without a VPN by publishing them through the Global Secure Access service. To expose WebApp1 to remote users, you must create an application segment that defines the application's internal address, port, and connector group. This segment routes traffic from the Global Secure Access client to the on-premises web app via the connector. Without an application segment, the service has no knowledge of how to reach WebApp1.

Correct Option:

A. Create an application segment.

An application segment in Microsoft Entra Private Access defines the on-premises application's FQDN or IP address, port, protocol, and which connector group handles the traffic. This is the core configuration that publishes WebApp1 to remote users.

Once the application segment is created, remote users with the Global Secure Access client can access the application using the same URL (https://webapp1.contoso.com) without needing a VPN, as the traffic is routed through the connector.

This step is mandatory to make the application available to users through Private Access.

Incorrect Option:

B. Create a Conditional Access policy.
Conditional Access policies enforce access controls (like MFA, compliant devices, or user risk) on applications. While you can create a Conditional Access policy to require MFA for WebApp1, this does not actually publish or expose the application to remote users.

Creating a Conditional Access policy is an additional security measure, not the primary action needed to ensure remote users can access WebApp1 via Private Access.

Incorrect Option:

C. Deploy Microsoft Entra Internet Access.
Microsoft Entra Internet Access is a separate component of Global Secure Access that secures access to internet and SaaS applications. It does not handle private on-premises applications.

The scenario specifically requires access to an on-premises web app (WebApp1), which is the domain of Microsoft Entra Private Access, not Internet Access. Deploying Internet Access would not help remote users reach WebApp1.

Incorrect Option:

D. Enroll the remote users' devices in Microsoft Defender for Endpoint.
Enrolling devices in Microsoft Defender for Endpoint provides security monitoring and threat protection, but it does not enable access to on-premises applications.

While device compliance can be used in Conditional Access policies to require compliant devices, enrolling in Defender for Endpoint is not a prerequisite or solution for accessing WebApp1 via Private Access.

Reference:

Microsoft Learn: Microsoft Entra Private Access overview

Microsoft Learn: Publish applications with Microsoft Entra Private Access

Microsoft Learn: Application segments in Global Secure Access

Microsoft Learn: Global Secure Access connectors

Microsoft Learn: Microsoft Entra Private Access vs Internet Access

Explanation:
Microsoft Entra Connect uses the proxyAddresses attribute for identity matching and soft-matching between on-premises users and existing cloud objects. The smtp: prefix (lowercase) indicates the primary SMTP address, while smtp: (uppercase) indicates secondary addresses. Soft-matching occurs when a proxy address in the on-premises object matches an existing cloud user. If a proxy address matches an object of a different type (e.g., a group), an ObjectTypeMismatch error occurs. If a proxy address is already used by another synced user, an AttributeValueMustBeUnique error occurs.

User1@contoso.com:

Original proxy addresses: smtp: user1@contoso.com (primary), smtp: sales@contoso.com (secondary)

Updated proxy addresses: smtp: admin@contoso.com (only one address shown)

Since User1 is being updated, the proxy address admin@contoso.com is now set. However, there is no existing user with admin@contoso.com in the cloud (assuming it's unique). The previous address sales@contoso.com is now removed.

The sync will attempt to update the user. If admin@contoso.com is not used by any other user, the sync succeeds.

Status: Successfully synced

User2@contoso.com:

Original proxy addresses: smtp: user2@contoso.com (primary), smtp: user2@contoso.com (duplicate), smtp: service@contoso.com (secondary)

Updated proxy addresses: smtp: sales@contoso.com

The proxy address sales@contoso.com is now being added to User2.

However, User1 previously had sales@contoso.com as a secondary proxy address. Even though User1 was updated to admin@contoso.com, the old sales@contoso.com address might still exist in the cloud as a stale proxy address or the new update might not have removed it yet.

If sales@contoso.com is already used by User1 in the cloud (even if removed from on-premises, the cloud object still has the proxy address), then User2 trying to use the same address will cause a conflict.

Alternatively, if sales@contoso.com is not used by any other synced user, the sync succeeds. However, given the scenario and typical exam patterns, this is likely a conflict.

Status: AttributeValueMustBeUnique (if sales@contoso.com is already used by another user) OR Successfully synced (if unique). Based on typical exam logic, the duplicate address causes an error.

User3@contoso.com:
New user: UPN user3@contoso.com, proxy addresses: smtp: user3@contoso.com (primary), smtp: sales@contoso.com (secondary)

The proxy address sales@contoso.com is already used by User1 (previously) and now being assigned to User2 as well. This creates a conflict because sales@contoso.com cannot be used by multiple users.

Reference:

Microsoft Learn: Azure AD Connect sync service attributes

Microsoft Learn: ProxyAddresses attribute synchronization

Microsoft Learn: Identity matching in Azure AD Connect

Microsoft Learn: Troubleshoot Azure AD Connect sync errors

Microsoft Learn: Soft-match and hard-match in Azure AD Connect

Microsoft Learn: AttributeValueMustBeUnique error in Azure AD Connect

Microsoft Learn: InvalidSoftMatch error in Azure AD Connect

Microsoft Learn: ObjectTypeMismatch error in Azure AD Connect

Explanation:
In Azure AD (now Microsoft Entra ID), assigning users to an enterprise application (App1) requires the Application Administrator or Cloud Application Administrator role. Registering a new application (App2) requires the Application Administrator, Cloud Application Administrator, or Application Developer role. The global administrator registered App1, making it an enterprise application. Users without admin roles cannot assign users to apps or register new apps under default settings. The principle of least privilege determines which roles have the necessary permissions for each task. Correct Option (Can assign users to App1):

Admin1 and Admin3 only

Admin1 has the Application Administrator role, which grants permissions to manage all aspects of enterprise applications, including assigning users to App1.

Admin3 has the Cloud Application Administrator role, which also grants permissions to manage enterprise applications, including user assignments.

Admin2 has the Application Developer role, which allows registration of applications but does not grant permissions to assign users to existing enterprise applications.

User1 is a standard user and cannot assign users to enterprise applications under default settings.

Correct Option (Can register App2 in Azure AD):

Admin1, Admin2, and Admin3 only

Admin1 (Application Administrator) can register applications in Azure AD.

Admin2 (Application Developer) can register applications in Azure AD, as this role is specifically designed for app registration and development. Admin3 (Cloud Application Administrator) can register applications in Azure AD.

User1 is a standard user and cannot register applications under default app registration settings (unless the tenant allows users to register applications, which is not specified and defaults to "No" in the default settings).

Reference:

Microsoft Learn: Azure AD built-in roles for app registration

Microsoft Learn: Manage enterprise applications in Azure AD

Microsoft Learn: Application Administrator role permissions

Microsoft Learn: Cloud Application Administrator role permissions

Microsoft Learn: Application Developer role permissions

Microsoft Learn: Default app registration settings in Azure AD

Microsoft Learn: Assign users to enterprise applications

Explanation:
Microsoft Entra Internet Access (part of Global Secure Access) is managed by users who hold the Global Secure Access Administrator role or the Global Administrator role.

Assuming the (unshown) table assigns:

User1 → Global Administrator or Global Secure Access Administrator

User2 → Global Secure Access Administrator

User3 → a role that does not include Global Secure Access management permissions (for example Security Administrator, Global Reader, or a lower-privileged role) Only User1 and User2 have the required permissions to manage Microsoft Entra Internet Access.

Reference:
Microsoft Entra built-in roles – Global Secure Access Administrator (“Create and manage all aspects of Global Secure Internet Access and Microsoft Global Secure Private Access”). Global Administrator also has full permissions.

Explanation:
Azure resources support different types of identities for access and management. Virtual machines (VM1) allow adding Microsoft Entra users and managed identities as virtual machine administrators for login purposes. Azure App Service web apps (App1) support assigning both system-assigned and user-assigned managed identities for authenticating to other Azure services. However, App1 does not directly support adding a Microsoft Entra user as an identity on the resource itself—the user would be assigned via RBAC roles, not added as an identity on the app.

Correct Option (VM1):

Managed1, Managed2, and User1
VM1 supports adding Microsoft Entra users and managed identities as part of the Virtual Machine Administrator Login or Virtual Machine User Login RBAC roles. This allows them to sign in to the VM using Entra credentials.

User1 is a Microsoft Entra user and can be added to VM1 via Azure RBAC (e.g., Virtual Machine Administrator Login role).
Managed1 and Managed2 are managed identities. Managed identities can be assigned to the VM itself (system-assigned) or added as user-assigned identities to the VM. However, to allow a managed identity to sign in to a VM, the identity must be assigned the appropriate RBAC role (like Virtual Machine Administrator Login) on the VM. Therefore, all three identities (User1, Managed1, and Managed2) can be added to VM1 via RBAC role assignments.

Incorrect Option (VM1):

User1 only / Managed2 only / Managed1 and Managed2 only / Managed2 and User1 only
These options incorrectly exclude certain identities. VM1 supports adding both users and managed identities. Any valid security principal (user, group, service principal, managed identity) can be assigned RBAC roles on VM1. Therefore, User1, Managed1, and Managed2 can all be added.

Correct Option (App1):

A system-assigned managed identity and Managed2 only
App1 (Azure App Service web app) supports two types of managed identities: system-assigned (enabled directly on the resource) and user-assigned (a separate resource like Managed1 or Managed2 that can be assigned to the app).

The system-assigned managed identity is created automatically when enabled on App1. This identity can be used to authenticate to other Azure services without managing credentials.

Managed2 is a user-assigned managed identity and can be assigned to App1 by adding it to the app's identity configuration.
User1 is a Microsoft Entra user and cannot be "added to" App1 as an identity on the app itself. While User1 can be granted RBAC permissions to manage App1, they are not an identity that the app uses to authenticate to other services. The app uses managed identities for that purpose.

Therefore, App1 can have a system-assigned managed identity and Managed2 (user-assigned) assigned to it.

Incorrect Option (App1):

A system-assigned managed identity only / User1 only / Managed2 only / Managed2 and User1 only / A system-assigned managed identity, Managed2, and User1
These options either exclude the user-assigned managed identity (Managed2) or incorrectly include User1. App1 cannot have User1 as an identity on the app—User1 would be assigned via RBAC, not as a managed identity. App1 supports both system-assigned and user-assigned identities, so the correct answer includes both types of managed identities.

Reference:

Microsoft Learn: Manage identities for Azure resources

Microsoft Learn: Assign a user-assigned managed identity to an Azure resource

Microsoft Learn: Azure App Service managed identities

Microsoft Learn: Add managed identities to a virtual machine

Microsoft Learn: Azure RBAC roles for virtual machine login

Explanation:
The user risk policy applies to Group1 and explicitly excludes Group2. The control “Require password change” is triggered for Medium and above user risk.

User1 belongs only to Group1 and has High risk → Policy applies → Must change password.

User2 belongs only to Group2 (excluded) → Policy does not apply, regardless of the Medium risk.

User3 belongs to both Group1 and Group2. Exclusion takes precedence, so the policy does not apply, even though the risk is High.

Reference:
Microsoft Entra ID Protection / Conditional Access – Include/Exclude group evaluation (Exclude always overrides Include).

Explanation:
When bulk inviting B2B collaboration users in Microsoft Entra ID, you use a CSV file to specify the list of guest users. The bulk invite process requires certain parameters to be included in the CSV file to successfully send invitations and redirect users appropriately. The mandatory parameters are the email address of the invitee and the redirection URL (the page the user is directed to after redeeming the invitation). Other parameters like username or password are either optional or generated automatically by the system.

Correct Option:

C. redirection URL
The redirection URL (also called the "invitation redirect URL") is a required parameter in the bulk invite CSV file. It specifies the custom page that the invited user will be directed to after they accept the invitation and complete the redemption process.

This ensures that the guest user lands on the correct application or portal after signing in. If not provided, Microsoft Entra ID redirects the user to the default My Apps page. This parameter is mandatory for a valid bulk invite file.

Correct Option:

E. email address
The email address (also called "InvitedUserEmailAddress") is the primary required parameter in the bulk invite CSV file. It specifies the email address of the external user to whom the invitation will be sent.

The email address must be unique and valid, as it is the key identifier for the guest user in the B2B collaboration process. This parameter is mandatory for the bulk invite file.

Incorrect Option:

A. shared key
A shared key is not a parameter used in B2B collaboration bulk invites. Shared keys are typically associated with Azure Storage account access keys or shared access signatures (SAS), not with user invitations.

There is no shared key element in the bulk invite CSV format. This option is irrelevant to the scenario.

Incorrect Option:

B. password
A password is not a required parameter in the bulk invite CSV file. When B2B guest users are invited, they use their existing credentials from their home tenant or Microsoft Account to authenticate. The invitation does not create a password for the guest in the resource tenant.

If the guest user does not have an existing account, they will go through a redemption flow to create one. The password is handled during that redemption process, not in the bulk invite file.

Incorrect Option:

D. username
The username (or "InvitedUserDisplayName") is an optional parameter in the bulk invite CSV file. While it can be included to set the display name for the guest user, it is not required.

The mandatory parameters for the bulk invite file are the email address and the redirection URL. The username is not required to process the bulk invitation.

Reference:

Microsoft Learn: Bulk invite B2B guest users

Microsoft Learn: CSV file format for bulk invite

Microsoft Learn: B2B collaboration invite parameters

Microsoft Learn: Redemption URL for B2B invitations

Microsoft Learn: Troubleshoot B2B collaboration invitation

Explanation:

User1 needs the User administrator, Device Administrators, and Identity Governance Administrator roles. These are Microsoft Entra ID (Azure AD) directory roles and are assigned in the Azure Active Directory admin center (Microsoft Entra admin center).

User2 needs the Records Management role and Quarantine Administrator role group. These are managed in the compliance/security area of Microsoft 365 (Records Management is in Microsoft Purview / compliance center; Quarantine Administrator is associated with Defender/Exchange Online protection features accessible via the compliance center).

User3 needs the Endpoint Security Manager and Intune Role Administrator roles. These are Intune-specific RBAC roles and are assigned in the Microsoft Endpoint Manager admin center (Microsoft Intune admin center).

Explanation:
Global Secure Access (GSA) in Microsoft Entra provides secure access to corporate resources by routing traffic through the Microsoft network. To enforce that users can only access resources when the GSA client is connected, you must first establish a remote network connection. This allows traffic to be routed through the GSA service. Creating a remote network is the foundational step that enables the connectivity required to enforce policies based on GSA client presence.

Correct Option:

C. Create a remote network.

A remote network in Global Secure Access represents the on-premises or cloud infrastructure that connects to the Microsoft network via a VPN or other connectivity method. This is the first step in setting up Global Secure Access.

Once the remote network is created, you can configure Conditional Access policies to require that traffic comes from the GSA client. The remote network provides the infrastructure that validates the client's connection status.

Without a remote network, Global Secure Access cannot function, as there is no path for traffic to route through the Microsoft network. Therefore, this is the prerequisite step.

Incorrect Option:

A. Enable tagging to enforce tenant restrictions.

Tenant restrictions and tagging are used to control access across multiple tenants, typically for data exfiltration prevention or cross-tenant access. While tagging can be used with Global Secure Access, it is not the first step.

Enabling tagging is a downstream configuration that relies on the remote network being established first. It does not directly ensure that the GSA client is connected.

Incorrect Option:

B. Create a named location.

Named locations in Conditional Access are used to define IP address ranges or countries for location-based policies. They are not used to detect whether the Global Secure Access client is connected.

While Conditional Access can reference named locations, the requirement is specific to the GSA client presence, which is not determined by IP address or named locations. This is not the correct first step.

Incorrect Option:

D. Enable Global Secure Access signaling.

GSA signaling is the mechanism by which the client's connection status is communicated to Conditional Access policies. However, this signaling cannot be enabled until the remote network is created and the infrastructure is in place.

Enabling signaling is a later step after the remote network is configured. Therefore, this is not the first action to take.

Reference:

Microsoft Learn: Global Secure Access overview

Microsoft Learn: Remote networks in Global Secure Access

Microsoft Learn: Configure Global Secure Access

Microsoft Learn: Conditional Access with Global Secure Access

Microsoft Learn: Global Secure Access client configuration

Explanation:

Admin1 (Global Administrator)
By default, the Global Administrator role has no permissions to read, define, or assign custom security attributes. A separate role (Attribute Assignment Administrator) is required.

Admin2 (Attribute Assignment Administrator)
This role can assign attribute values to supported objects (users and service principals), but it cannot modify the attribute definition itself. Modifying Attribute1 requires the Attribute Definition Administrator role.

Assignment to Group1
Custom security attributes can be assigned only to users and service principals. They cannot be assigned to security groups.

Reference:
Microsoft Learn – Custom security attributes overview and role permissions (Attribute Assignment Administrator vs Attribute Definition Administrator).