SC-300 Practice Questions

To implement a Microsoft Defender for Cloud Apps session policy, you must first route the relevant user sessions to Defender for Cloud Apps. This is achieved by creating an Azure Active Directory (Azure AD) Conditional Access policy. Within this policy, you configure the "Session" control to use "Conditional Access App Control." This action redirects the user's session through the Defender for Cloud Apps reverse proxy, making it possible to apply the session policies you create within the Defender for Cloud Apps portal. Therefore, creating the Conditional Access policy is the necessary first step in the deployment process.

A. User monitoring is a feature for viewing user activity logs and investigating alerts, not for creating session control policies.

B. While the app must be connected (onboarded), the Conditional Access policy is the specific trigger that initiates session control for that app.

D. Creating a continuous report is used for exporting logs and data for analysis, which is unrelated to the creation of real-time session policies.

1. Microsoft Learn. (2023). Deploy Conditional Access App Control for featured apps. "Step 1: Configure Azure AD to work with Defender for Cloud Apps". This section explicitly details the first step as creating an Azure AD Conditional Access policy and selecting "Use Conditional Access App Control" under Session controls.

2. Microsoft Learn. (2023). Session policies. In the "Prerequisites to use session policies" section

it states

"The relevant apps should be deployed with Conditional Access App Control

" confirming that the Conditional Access configuration is a prerequisite.

3. Microsoft Learn. (2023). SC-300: Implement access management for apps - Implement session policies in Microsoft Defender for Cloud Apps. This training module states

"To route sessions to Defender for Cloud Apps

you configure Azure AD Conditional Access policies to include Conditional Access App Control session controls." This directly identifies the Conditional Access policy as the starting point.

The "External collaboration settings" in Azure Active Directory (Azure AD) provide the central administrative controls for managing how guest users are invited into the tenant. These settings determine who can invite guests (administrators, members, or specific roles), whether guest self-service sign-up is enabled, and any domain-specific restrictions (allow or deny lists) for invitations. Therefore, to resolve an issue with guest user invitations, such as invitations failing or being blocked, the first and most direct place to investigate and configure is the External collaboration settings.

A. Configure the Continuous access evaluation settings.

Continuous Access Evaluation (CAE) revokes access tokens in near real-time based on critical events. It governs active sessions, not the initial user invitation process.

C. Configure the Access reviews settings.

Access reviews are a governance feature used to periodically review and manage existing user access to resources. They do not control the initial invitation of guest users.

D. Configure a Conditional Access policy.

Conditional Access policies enforce controls like multi-factor authentication during sign-in, after a user has been successfully invited and is attempting to access resources. They do not manage the invitation process itself.

1. Microsoft Learn. "Configure external collaboration settings." Microsoft Entra documentation. Accessed October 2023. In this document

under the "Guest invite settings" section

it explicitly details the policies for controlling guest user invitations

such as "Guest invite restrictions" and "Allow or block domains." This is the primary location for resolving invitation issues.

2. Microsoft Learn. "Conditional Access for B2B collaboration users." Microsoft Entra documentation. Accessed October 2023. This page clarifies that Conditional Access policies are applied to B2B guest users "when they access a resource in a resource tenant

" which occurs after the invitation has been accepted.

3. Microsoft Learn. "What are Azure AD access reviews?" Microsoft Entra documentation. Accessed October 2023. The overview states

"Azure Active Directory (Azure AD) access reviews enable organizations to efficiently manage group memberships

access to enterprise applications

and role assignments

" confirming its role in managing existing access

not invitations.

4. Microsoft Learn. "Continuous access evaluation." Microsoft Entra documentation. Accessed October 2023. The introduction explains that CAE is for revoking access tokens based on "critical events and policy evaluation

" which relates to post-authentication session management

not the invitation workflow.

The access review in image_d03e96.png uses (Preview) Manager as the primary reviewer type.In Microsoft Entra ID access reviews, if the target user profiles do not have a designated manager configured in their user account attributes, the system automatically redirects the review request to the specified fallback reviewer, who is Megan Bowen in this scenario. Modifying the properties of the 100 IT administrator user accounts to explicitly specify their correct manager populates the required attribute. Consequently, the access review engine will identify the correct managers and route the respective department reviews to them instead of falling back to Megan Bowen.

B. No: This option is incorrect because modifying the user account properties to assign the correct manager attribute directly resolves the root cause causing the fallback behavior.

Official Vendor Documentation: Configure access reviewers using access reviews APIs - Microsoft Graph | Microsoft Learn Official Vendor Documentation: Microsoft Entra ID Governance deployment guide to assign employee access | Microsoft Learn (Section: Automated decision criteria / Inactive user reviews note regarding manager attributes)Official Vendor Documentation: How to create access review with fallback_reviewers | Microsoft Learn Answers (Documenting fallback behavior when manager property is missing)

Azure AD Application Proxy is a feature designed specifically to publish on-premises web applications and make them securely accessible to remote users. It acts as a reverse proxy, allowing users to connect to the on-premises app using their Azure AD credentials for pre-authentication and single sign-on (SSO). This solution meets the technical requirement of providing external access to an internal application without requiring a VPN or exposing the application server directly to the internet.

A. A policy set in Microsoft Endpoint Manager is used for managing device compliance, security settings, and configurations, not for publishing on-premises web applications.

B. An app configuration policy in Microsoft Endpoint Manager is used to deploy settings to managed applications (e.g., Outlook, Edge) on user devices, not for server-side application access.

C. An app registration in Azure AD is a necessary prerequisite for Application Proxy, as it creates an identity for the app, but it is not the complete solution for publishing it.

1. Microsoft Entra documentation. (2023). Plan an Azure Active Directory Application Proxy deployment. Microsoft Learn. Retrieved from https://learn.microsoft.com/en-us/azure/active-directory/app-proxy/application-proxy-deployment-plan. In the "What is Application Proxy?" section

it states

"Azure Active Directory's Application Proxy provides secure remote access to on-premises web applications."

2. Microsoft Entra documentation. (2023). Tutorial: Add an on-premises application for remote access through Application Proxy in Azure Active Directory. Microsoft Learn. Retrieved from https://learn.microsoft.com/en-us/azure/active-directory/app-proxy/application-proxy-add-on-premises-application. Step 1

"Add an on-premises app to Azure AD

" clarifies that you first register the app (related to option C) and then configure the proxy service (option D) to enable access.

3. Microsoft Intune documentation. (2023). App configuration policies for Microsoft Intune. Microsoft Learn. Retrieved from https://learn.microsoft.com/en-us/mem/intune/apps/app-configuration-policies-overview. This document explains that app configuration policies are for client-side apps on managed devices

which is distinct from providing remote access to a web application.

An OAuth app policy in Microsoft Defender for Cloud Apps is specifically designed to manage and create alerts for third-party applications that users have authorized via OAuth. This policy type allows an administrator to define rules based on the app's properties, such as its permission level (e.g., high, medium, low) and the number of users who have granted it consent. The scenario requires an alert when a high-permission app is authorized by more than 20 users, which directly aligns with the filtering capabilities of an OAuth app policy.

A. anomaly detection policy: These policies use machine learning to identify unusual user behavior based on established baselines, not for creating alerts based on predefined app attributes like permission level and user count.

C. access policy: These are real-time session controls, part of Conditional Access App Control, used to monitor or block user access to specific applications, not to alert on the characteristics of authorized OAuth apps.

D. activity policy: These policies trigger alerts based on specific user activities (e.g., mass download, multiple failed sign-ins), not on the cumulative state or attributes of an application itself.

---

1. Microsoft Learn. (2023). Manage OAuth apps.

Section: "Create OAuth app policies"

Content: This document explicitly states

"You can create OAuth app policies to automatically notify you when an OAuth app meets certain criteria." It lists the available filters for creating a policy

which include "Permission level" and "Users" (the number of users using the app)

directly matching the requirements in the question.

2. Microsoft Learn. (2023). Control cloud apps with policies.

Section: "Policy types"

Content: This page provides an overview of different policy types. It describes "OAuth app policies" for alerting on "suspicious OAuth apps

" "Access policies" for "real-time monitoring and control

" and "Activity policies" for alerting on "suspicious activity." This distinction supports the choice of OAuth app policy for the given scenario.

3. Microsoft Learn. (2023). Anomaly detection policies in Microsoft Defender for Cloud Apps.

Section: "How anomaly detection policies work"

Content: This source details that anomaly detection policies work by profiling the environment and triggering alerts on activities that are anomalous compared to a learned baseline. This confirms it is not the correct tool for a rule with static

predefined thresholds.

To grant users from the Contoso East division access to SharePoint Online sites in the Contoso West tenant without incurring extra licensing costs, you should invite them as guest users using Microsoft Entra ID (formerly Azure AD) B2B collaboration. SharePoint Online natively supports external sharing with guest accounts. Under the Microsoft Entra External Identities pricing model, the first 50,000 Monthly Active Users (MAU) are free, fulfilling the requirement of not needing additional Microsoft 365 licenses.

A: A single Microsoft Entra Connect server cannot sync to multiple distinct Microsoft Entra ID (Azure AD) tenants simultaneously; it supports a 1:1 tenant mapping.

B: Microsoft Entra Application Proxy is designed to provide secure remote access to on-premises web applications, not to share native cloud-based services like SharePoint Online across separate tenants.

C: While an on-premises forest can sync to multiple tenants via separate sync servers, it creates distinct cloud identities requiring management and does not natively grant external access as cleanly or cost-effectively as B2B guest collaboration.

Official Vendor Documentation: Microsoft Learn, What is Microsoft Entra B2B collaboration?, Section: "Key benefits of Microsoft Entra B2B collaboration".

Official Vendor Documentation: Microsoft Learn, External sharing overview - SharePoint in Microsoft 365, Section: "How the external sharing model works".

Official Vendor Documentation: Microsoft Learn, Billing model for Microsoft Entra External Identities, Section: "Monthly active users (MAU) billing model".

The Client apps condition within an Azure AD Conditional Access policy is the specific control used to identify and filter authentication requests based on the client application type. To block legacy authentication, an administrator configures this condition to target "Legacy authentication clients." This category includes older mail protocols like POP, IMAP, SMTP, and other clients that do not support modern authentication. By applying a block control to sign-ins matching this condition, organizations can effectively prevent users from using these less secure protocols, thereby enhancing their security posture.

A. A cloud apps or actions condition targets specific applications (e.g., Exchange Online) or user actions, not the authentication protocol used to access them.

B. A user risk condition is part of Azure AD Identity Protection and triggers policies based on a user's compromised state, not the sign-in protocol.

D. A sign-in risk condition evaluates the real-time risk of a sign-in attempt (e.g., anonymous IP) but does not inherently filter by authentication type.

1. Microsoft Learn. (2023). Conditional Access: Conditions. In "Azure Active Directory documentation". Retrieved from https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/concept-conditional-access-conditions#client-apps.

Reference Details: Under the "Client apps" section

the document states

"This condition allows a Conditional Access policy to target specific client applications... By configuring the client apps condition

you can distinguish between... modern authentication clients and legacy authentication clients."

2. Microsoft Learn. (2023). How to: Block legacy authentication to Azure AD with Conditional Access. In "Azure Active Directory documentation". Retrieved from https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/block-legacy-authentication.

Reference Details: The section "Create a Conditional Access policy" explicitly instructs to navigate to Conditions > Client apps and select Legacy authentication clients to create the policy that blocks these protocols.

Microsoft Entra Terms of Use (ToU) are enforced through Conditional Access policies. To meet the requirement, an administrator first uploads the custom ToU document within Microsoft Entra Identity Governance. Then, a Conditional Access policy is configured to apply to the desired users and cloud applications. Within this policy, the "Terms of Use" option is selected as a grant control. When a targeted user signs in, the policy triggers, and the user is blocked from accessing resources until they review and accept the specified ToU agreement. This is the designated method for this purpose.

A. an access package: Access packages, part of Entitlement Management, are used to bundle resources (groups, apps, sites) that users can request, not to enforce a global ToU at sign-in.

C. a lifecycle workflow: Lifecycle workflows automate identity-based tasks for users joining, moving within, or leaving an organization, but they do not present agreements during the sign-in process.

D. an authentication method: Authentication methods (e.g., password, authenticator app, FIDO2 key) are credentials used to verify a user's identity, not to enforce policy agreements like a ToU.

1. Microsoft Entra documentation

"Terms of use": "Microsoft Entra terms of use (ToU) provides a simple method that organizations can use to present information to end users... To require a terms of use policy to be accepted

you'll need a Conditional Access policy." (Microsoft Learn

Microsoft Entra > Identity Governance > Terms of use

"Prerequisites" section).

2. Microsoft Entra documentation

"Conditional Access: Grant": This document lists the available access controls for Conditional Access policies. It explicitly states

"Require terms of use - This control requires the user to consent to the terms of use that has been configured in the tenant." (Microsoft Learn

Microsoft Entra > Conditional Access > Policies > Grant

"Require terms of use" section).

3. Microsoft Entra documentation

"What are access packages and what resources can I manage with them?": "Entitlement management introduces the concept of an access package. An access package is a bundle of all the resources with the access a user needs to work on a project or perform their task." (Microsoft Learn

Microsoft Entra > Identity Governance > Entitlement management

"What are access packages" section).

The requirement is to grant an external contractor, using their personal outlook.com Microsoft Account (MSA), access to an enterprise application. The standard and most appropriate method for this in Azure AD is B2B collaboration. This involves inviting the external user as a guest. The invitation process creates a guest user account object in the contoso.com tenant that is linked to the contractor's external identity ([email protected]). This allows the contractor to authenticate using their existing credentials while enabling you to assign them permissions to internal resources like App1.

A. Run the New-AzADUser cmdlet.

This cmdlet creates a new member user, which is an internal account with credentials managed by your tenant, not a guest who uses their own identity.

B. Configure the External collaboration settings.

These settings define policies for B2B collaboration (e.g., who can invite guests) but do not perform the action of inviting a specific user.

C. Add a WS-Fed identity provider.

This is for setting up direct federation with an organization's identity provider (like ADFS), not for individual Microsoft Accounts like outlook.com.

---

1. Microsoft Learn

"What is Azure Active Directory B2B collaboration?": "Azure AD B2B collaboration is a feature within External Identities that lets you invite guest users to collaborate with your organization. ... Guest users sign in to your apps and services with their own work

school

or social identities." This directly supports using B2B collaboration for external users with social identities like an MSA.

Source: Microsoft Documentation

Azure Active Directory > External Identities > What is B2B collaboration?

Introduction section.

2. Microsoft Learn

"Add Azure Active Directory B2B collaboration users in the Azure portal": "You can invite guest users to the directory

to a group

or to an application. After you send the invitation

the user account is automatically added to the directory as a guest." This confirms that the action of inviting results in the creation of a guest user account.

Source: Microsoft Documentation

Azure Active Directory > External Identities > How-to guides > Add B2B collaboration users in the Azure portal

"Invite a guest user to your directory" section.

3. Microsoft Learn

"Properties of an Azure Active Directory B2B collaboration user": "A B2B collaboration user is a user with UserType set to Guest. This guest user in your directory is the result of inviting a guest user to collaborate..." This document explicitly defines the outcome of an invitation as a user object with the type "Guest".

Source: Microsoft Documentation

Azure Active Directory > External Identities > User properties > Properties of a B2B guest user

"Before and after invitation" section.

When performing a bulk invitation for Azure AD B2B collaboration users, a comma-separated values (CSV) file is used. According to the official Microsoft documentation, this CSV file template has two mandatory fields that must be populated for each user you want to invite. The first is the Invited user email address, which is the identity of the external user receiving the invitation. The second is the Redirection url, which is the location the user is sent to after they accept the invitation, such as a specific application or the My Apps portal.

C. username: The User Principal Name (UPN) for a B2B guest is automatically generated from their email address and is not a required input field in the bulk invite CSV file.

D. shared key: Shared keys are credentials used for service principals or applications and are not relevant to the process of inviting individual B2B collaboration users.

E. password: B2B collaboration users authenticate using the credentials from their home identity provider. The inviting tenant does not set or manage a password for them.

1. Microsoft Entra ID Documentation. "Tutorial: Bulk invite Azure AD B2B collaboration users." Microsoft Learn. Under the section "Understand the CSV template

" the table lists "Invited user email address" and "Redirection url" as Required. It states

"The email address of the user to invite" and "The URL to which the invited user is forwarded after accepting the invitation."

2. Microsoft Entra ID Documentation. "Properties of an Azure Active Directory B2B collaboration user." Microsoft Learn. This document clarifies that the User Principal Name (UPN) is typically constructed from the invited user's email address

confirming that the email address is the primary input. It also reinforces that authentication is handled by the user's home directory

making a password from the inviting tenant unnecessary.