SC-300 Questions and Answers

According to the Microsoft SC-300: Identity and Access Administrator official study guide and the Microsoft Learn “Implement and manage Azure AD Identity Protection” module, Azure AD Identity Protection detects two primary categories of risks: user risks and sign-in risks.

User Risk Policy: A user risk represents the probability that a user ' s identity (credentials) has been compromised. Examples of user risk signals include leaked credentials , unusual sign-ins from different geographies , or sign-ins from infected devices . The Exam Ref SC-300 specifically lists “leaked credentials detected on the dark web or other compromised repositories” as the main trigger for a user risk policy. Such a policy can automatically force password change or enforce MFA to remediate the threat.

Sign-in Risk Policy: A sign-in risk reflects the likelihood that a specific authentication attempt is not performed by the legitimate user. Sign-in risk is based on context, such as sign-ins from suspicious browsers , anonymous IP addresses (like TOR networks) , or impossible travel sce narios . The SC-300 documentation highlights these examples as conditions best handled with a sign-in risk policy, where conditional access can block or require MFA for the risky sign-in attempt.

Therefore:

Leaked credentials are addressed through a User Risk Policy, since the account itself is compromised.

Sign-ins from suspicious browsers and access from anonymous IP addresses are handled through Sign-in Risk Policies, as they relate to risky sessions rather than compromised identities.

In Azure AD Privileged Identity Management (PIM), the SC-300 materials explain that role assignment type determines how a user obtains permissions. An eligible assignment means the user requests activation when needed; an active assignment grants continuous permissions. As the guide states, “Eligible assignments require the user to activate the role for just-in-time access, while active assignments grant standing access.” To allow users of the User administrator role to request the role when needed , you must set assignments to Eligible rather than active.

The same objective also calls for ensuring this capability is available “for up to one year.” In PIM role configuration, the duration of an eligibility is controlled by the Expire eligible assignments after policy. The documentation describes that administrators can “configure the maximum duration for eligible assignments by setting ‘Expire eligible assignments after’ to a specific period (for example, months up to one year).” Therefore, you must modify the “Expire eligible assignments after” setting to the required period.

No requirement mentions activation justification or ticket metadata; those are optional controls used to add context to activations. Consequently, the two actions that directly satisfy the stated technical requirement are: set all assignments to Eligible (C) and configure “Expire eligible assignments after” (D) .

In Azure AD Identity Governance, application access granted through Entitlement management is organized around catalogs and access packages. The SC-300 study materials explain that “a catalog is a container for resources and access packages” and that you must add your enterprise applications (or the groups tied to those apps) to a catalog before you can build access packages that users can request. Creating the catalog first enables you to place only the required resources in scope and to delegate day-to-day ownership: “catalog owners can manage the resources and access packages within their catalog without being tenant-wide admins,” satisfying the delegation requirement to use custom catalogs and least privilege. After the catalog exists, you create one or more access packages that include the application (or groups) and policies that control who can request, how they are approved, and for how long. Identity Governance then lets you track access package assignments and review who has the app over time. By contrast, programs are used to group and report on governance initiatives (for example, collections of access reviews) rather than to onboard application resources; and modifying user/admin consent settings affects app consent behavior, not the lifecycle tracking of assignments. Therefore, the correct first step to track application access assignments while meeting the delegation requirements is to create a catalog.

According to the Microsoft SC-300: Identity and Access Administrator Study Guide and Microsoft Learn modules “Implement and manage Azure AD roles” and “Implement Privileged Identity Management (PIM)” , there is a clear distinction between Azure AD built-in roles and Azure (resource-based) built-in roles.

Azure AD built-in roles govern directory-level access — such as managing users, groups, enterprise apps, or security settings in Azure Active Directory (Entra ID). The Privileged Role Administrator role allows the user to manage role assignments for directory roles in Azure AD, including activating roles through PIM. The Global Administrator also has this capability, but the Privileged Role Administrator is the least privilege role that meets the delegation requirement — aligning with the principle of least privilege stated in the scenario. As the documentation notes:

“Privileged Role Administrator manages role assignments in Azure AD, including the ability to activate and assign roles through Azure AD Privileged Identity Management.”

Azure built-in roles, on the other hand, are used to control access at the Azure resource level — for subscriptions, resource groups, and individual resources. The role responsible for managing these assignments is the User Access Administrator. This role can grant or revoke access to Azure resources by managing role assignments within Azure RBAC (Role-Based Access Control). The Microsoft documentation states:

“User Access Administrator allows management of user access to Azure resources. It can assign roles in Azure RBAC for resources, subscriptions, and management groups.”

Therefore:

✅ To manage Azure AD built-in role assignments → Privileged role administrator

✅ To manage Azure built-in role assignments → User access administrator

This approach satisfies the delegation requirement mentioned in the scenario by assigning the least-privileged roles necessary for each type of role management task.

According to the Microsoft SC-300: Identity and Access Administrator Study Guide and the Microsoft Learn module “Monitor and respond to Azure AD events with Azure Sentinel” , multi-staged attacks are advanced threat scenarios that require correlation of multiple events — for example, a suspicious sign-in followed by abnormal Office 365 activity.

The scenario in the question states:

“Litware wants to use the Fusion rule in Azure Sentinel to detect multi-staged attacks that include a combination of suspicious Azure AD sign-ins followed by anomalous Microsoft Office 365 activity.”

Azure Sentinel’s Fusion rule is a built-in, machine-learning–driven correlation rule that automatically detects multi-stage attacks by analyzing anomalies across multiple data sources such as Azure AD sign-in logs, Office 365 activity, and security alerts.

However, to fine-tune detection or meet specific organizational monitoring requirements, administrators can customize the rule logic in Sentinel analytics. This allows you to define how different signals and events are correlated, what thresholds trigger an alert, and how Sentinel interprets combined anomalies.

Microsoft documentation states:

“Fusion uses correlation logic in analytics rules to detect complex multi-stage attacks. Administrators can customize rule logic to meet specific detection requirements and fine-tune alert sensitivity.”

The other options do not meet the requirement:

B. Create a workbook → Used for visualization and reporting, not detection.

C. Add data connectors → Used to ingest data sources; this is already configured.

D. Add a playbook → Used for automated response, not for detection logic configuration.

✅ Correct Answer: A. Customize the Azure Sentinel rule logic

According to the Microsoft Identity and Access Administrator (SC-300) Exam Ref and the Azure AD Dynamic Membership Rules documentation , when you create a dynamic group in Azure Active Directory (now Entra ID), you define rules that automatically add or remove users based on their attributes.

The scenario requires a group named LWGroup1 that contains all Azure AD user accounts for Litware but excludes all guest accounts . In Azure AD, internal users created within the tenant are designated with the attribute user.userType = " Member " , while external or guest accounts from partner organizations have user.userType = " Guest " .

To ensure only internal (Litware) users are included, the membership rule must:

Ensure the user object exists — by checking (user.objectId -ne null) which confirms that the rule only applies to valid user objects.

Include only members, excluding guests — by filtering with (user.userType -eq " Member " ) .

Hence, the dynamic rule that satisfies these conditions is:

(user.objectId -ne null) and (user.userType -eq " Member " )

This rule guarantees that LWGroup1 dynamically includes all internal users from litware.com and excludes all external users or guest accounts (such as Fabrikam users).

This logic aligns precisely with the Microsoft Learn module “Manage groups in Azure Active Directory” and SC-300 study guide section “Implement and manage dynamic membership rules” , which states:

“Use user.userType to distinguish between internal members and external guests when configuring membership rules for dynamic groups.”

✅ Correct Answer:

(user.objectId -ne null) and (user.userType -eq " Member " )

In SC-300, Azure AD Identity Protection is the prescribed control to “automatically detect and remediate externally leaked credentials.” That specific user risk—Leaked credentials—relies on Microsoft comparing known breached username/password pairs with what Azure AD can evaluate. The study materials explain that Identity Protection “detects leaked credentials when Microsoft finds a match with the user’s current credentials,” and also note that password hash synchronization (PHS) can be enabled even if your sign-in method is Pass-through Authentication or federation. A common exam call-out is that without PHS, Azure AD has no hash to compare, so the leaked-credential signal is unavailable. Enabling PHS (you can keep PTA as the active sign-in method) allows Identity Protection to raise user risk and enforce policy actions such as require password change or block access. By contrast, Azure AD Password Protection addresses banned/weak passwords at change time, not breached-credential telemetry; federation choices (e.g., PingFederate) don’t deliver the leaked-credential signal; and authentication method policy controls how users perform MFA (e.g., methods) rather than whether leaked credentials are detected. Therefore, to meet the requirement to “automatically detect and remediate externally leaked credentials,” the minimum correct step is to enable password hash synchronization while retaining PTA—exactly as recommended in SC-300 guidance.

SC-300 emphasizes using Conditional Access with named locations to scope MFA—especially to exclude trusted corporate egress IPs . The materials state that administrators can define named locations by public IP ranges and “mark them as trusted” for policy exceptions. This aligns with the requirement: enforce MFA for all users, but exempt users authenticating from the Boston office. Because Azure AD evaluates the client’s public egress address, private RFC1918 ranges are never seen by Azure AD on the internet, so defining private IP ranges would not work. Likewise, the legacy “Trusted IPs” setting belongs to the old per-user MFA service settings; SC-300 guidance prefers Conditional Access named locations for modern MFA deployments and for combining with other conditions (apps, platforms, user risk, locations). Implementing the Boston office as a named location using its public egress IP range(s), and marking it trusted, lets you exclude that location from the tenant-wide MFA policy while still meeting the broader requirement to enforce MFA for everyone else and for on-prem apps published via Azure AD Application Proxy. In short: define Boston’s public IP as a named location and use it in your Conditional Access policy exclusion to satisfy the exemption precisely and securely.

Server1

On DC1

Azure AD Password Protection has two components: the DC agent (installed on domain controllers) and the proxy service (installed on one or more member servers). The SC-300 materials and Microsoft Identity Governance guidance explain that the proxy service is required when domain controllers do not have direct internet access. The proxy retrieves the password protection policy and custom banned password list from Azure AD over outbound HTTPS and makes it available to DC agents. The documentation further states that you should deploy at least one proxy per forest and two for high availability, and that domain controllers do not need internet connectivity when a proxy is deployed. In this scenario, DCs are explicitly blocked from internet access, so the proxy must be placed on member servers. Both SERVER1 (Application Proxy connector) and SERVER2 (Azure AD Connect) are domain-joined member servers with internet connectivity and are appropriate locations for the AzureADPasswordProtectionProxy service; selecting both provides the recommended redundancy. The custom banned password list is configured in Azure AD at the tenant level (as part of Azure AD Password Protection settings), not on individual servers. Once configured, the policy and list are downloaded by the proxy and enforced by the DC agent during password set or change operations, satisfying the requirement to implement a banned password list for the litware.com forest.

SC-300 materials stress that to enforce modern controls (like MFA) on on-premises apps, you must front them with Azure AD so Conditional Access can evaluate sign-ins. The documentation states that Azure AD Application Proxy “ provides secure remote access to on-premises applications ” and that apps published through it can have “ Conditional Access policies, including multifactor authentication ” applied at sign-in. In other words, once the legacy app is published by Application Proxy, Azure AD sits in the path, enabling you to meet the requirement to enforce MFA when accessing on-premises applications and to combine it with your location-based exemptions.

For SharePoint Online restrictions, SC-300 points to Microsoft Cloud App Security (Defender for Cloud Apps) for real-time governance: you can create session policies that “ control and limit activities in real time ” and, for SharePoint Online and other Microsoft 365 apps, “ monitor user sessions and block download, cut, copy, and print ” when conditions (device state, risk, or location) warrant it. Since the scenario already has anomaly detections enabled, configuring Cloud App Security policies aligns directly with the requirement to place access restrictions on SharePoint Online without altering tenant-wide consent settings. Thus, publish on-prem apps with Application Proxy to bring them under Conditional Access (for MFA), and use Cloud App Security policies to enforce SharePoint Online session and download controls.

Assigning built-in directory roles (like Device Administrators) to a group requires a role-assignable group. The SC-300 documentation explains: “You can assign Azure AD roles to a cloud security group by creating the group with the setting ‘Azure AD roles can be assigned to the group.’” It further emphasizes: “This attribute is immutable; you must decide at creation time. You cannot convert an existing group to be role-assignable later.” When a standard security group is not created as role-assignable, it will not appear in the picker when attempting to assign a directory role—exactly the behavior observed: “groups that aren’t role-assignable cannot be selected for Azure AD role assignments.” Therefore, the first step is to recreate IT_Group1 as a role-assignable security group (often called an “eligible for role assignment” group) and then assign the Device Administrators role to that group. Changing membership types (Dynamic User or Dynamic Device) or adding owners does not convert an existing group into a role-assignable one and thus would not resolve the issue.

In the SC-300 materials covering Azure AD MFA configuration, Microsoft distinguishes between Notifications (which control whether the Microsoft Authenticator sends push prompts) and Fraud alert settings (which determine what happens when a user reports an unexpected prompt). The study guide notes that notifications “enable push approvals to the app,” but this does not take action when a user reports a suspicious prompt. To satisfy the requirement “block the users automatically when they report an MFA request they didn’t initiate,” you must use Fraud alert options. The documentation states that administrators can “allow users to submit fraud alerts” and “block users who report fraud” so that “reported accounts are immediately blocked until an administrator unblocks them.” These options are part of the tenant’s MFA service settings, not the Notifications section. In other words, simply configuring Notifications won’t automatically block users who tap Report in Microsoft Authenticator; you must explicitly enable the setting to block users upon fraud reports. Therefore, the proposed solution—changing Notifications settings—does not meet the goal. The correct approach is to enable Fraud alert and select Block users who report fraud, ensuring automatic protection when users report unexpected MFA prompts.

The User Administrator role allows management of user accounts, licenses, and group memberships within Azure AD but does not grant access to security configurations, Secure Score dashboards, or improvement actions.

According to Microsoft’s Secure Score documentation:

“Only users with Global Administrator, Security Administrator, or Security Reader roles can access Microsoft Secure Score. To modify improvement action statuses, the user must be a Security Administrator or Global Administrator.”

Therefore, a User Administrator cannot update Secure Score improvement actions.

In the SC-300 coverage of Azure AD Connect and Identity Governance, Microsoft explains that to surface a custom on-premises attribute in Azure AD you must enable Directory extensions in Azure AD Connect. The guide states that “Directory extensions lets you synchronize additional attributes from on-premises Active Directory to Azure AD so they are available in the cloud directory for apps and policy.” This is the supported way to bring a custom attribute (here, LWLicenses ) from the litware.com forest into Azure AD so it can be referenced by cloud features such as dynamic group rules. Domain filtering or optional features do not expose a new attribute to Azure AD; directory extensions does.

For license automation, the SC-300 materials on group-based licensing and dynamic groups emphasize that “licenses can be assigned to Azure AD groups; group members then inherit the licenses, and when membership changes, licenses are added or removed automatically.” They further note that “dynamic user groups evaluate rules against user attributes to add or remove users without manual effort,” and that “nested groups are not supported for license inheritance—only direct members receive licenses.” Using the synced LWLicenses attribute in a Dynamic User group rule (for example, user.extensionAttribute… -eq " E5 " ) ensures users are automatically added to the correct group and therefore receive the specified licenses without administrative intervention, fully meeting Litware’s requirement to “manage the assignment of Azure AD licenses by modifying the value of the LWLicenses attribute.”

According to the Microsoft SC-300 Study Guide and Microsoft Learn module: “Manage Microsoft 365 group lifecycles” , group expiration policies in Microsoft Entra ID apply only to Microsoft 365 groups (formerly Office 365 groups).

Group expiration is part of lifecycle management for Microsoft 365 services and helps ensure that unused groups are automatically deleted after a defined period unless renewed by the owner.

From the table:

Group1 (Security) → Cannot be set to expire.

Group2 (Microsoft 365) → Can be set to expire.

Group3 (Mail-enabled security) → Cannot be set to expire.

Group4 (Distribution) → Cannot be set to expire.

Therefore, Group2 only can have an expiration policy applied.

Regarding group lifetime, the Exam Ref SC-300 and Microsoft documentation confirm that the minimum (shortest) group lifetime that can be configured for Microsoft 365 group expiration policies is 30 days.

Microsoft Learn states:

“The group lifetime can be set to 30, 60, 90, 180, or 365 days. The minimum allowed is 30 days.”

This ensures group owners have sufficient time to renew or manage expiring groups before automatic deletion.

In Microsoft Entra ID (Azure AD), the per-user device cap is controlled in Devices > Device settings. The SC-300 materials describe that administrators can configure “Users may join devices to Azure AD” and the “Maximum number of devices per user” . The guide notes that this limit defaults to five and is used to “control how many devices a user can join or register in Azure AD”; when users reach the limit, “they cannot add additional devices until the limit is increased or an existing device is removed.” For scenarios like field or sales staff who use multiple devices, the study content recommends adjusting this value to meet business needs. Because A. Datum’s sales users hit the current cap and a requirement states “Increase the maximum number of devices that can be joined or registered to Azure AD to 10,” the fix is to change the tenant’s Device settings—not User settings, Access reviews, or Security defaults. This aligns with the exam objective to configure device settings for Azure AD join and registration and addresses the precise symptom reported by users.

User1 must request access to App1 before they can use the app: No

If User2 requests access to App1, they will be added to Group1 automatically: Yes

User2 can approve App1 requests by using the Microsoft Entra admin center: Yes

Let’s break this down step by step based on Microsoft Entra ID self-service application access and the configured settings, as outlined in Microsoft Identity and Access Administrator documentation.

Understanding Self-Service Application Access in Microsoft Entra ID:

Self-service application access in Microsoft Entra ID allows users to request access to applications without needing an administrator to manually assign them. This is configured on a per-application basis.

The settings for App1 are:

Allow users to request access to this application: Yes– Users can request access to App1.

To which group should assigned users be added: Group1– Users who are granted access will be added to Group1, which provides the necessary permissions to use App1.

Require approval before granting access to this application: Yes– Access requests must be approved before the user is added to Group1.

Who is allowed to approve access to this application: User2– User2 is the designated approver for access requests to App1.

Statement 1: User1 must request access to App1 before they can use the app.

Analysis:

User1 is already a member of Group1, as stated in the question.

The self-service settings specify that users who are granted access to App1 will be added to Group1. This implies that membership in Group1 is what grants access to App1.

Since User1 is already a member of Group1, they already have access to App1. In Microsoft Entra ID, if a user is already assigned to an application (either directly or via group membership), they do not need to request access through the self-service process—they can simply use the app.

The self-service access request process is for users who are not yet assigned to the app (i.e., not in Group1). Since User1 is already in Group1, they do not need to request access.

Conclusion:This statement isNo. User1 does not need to request access because they are already a member of Group1 and can use App1 immediately.

Statement 2: If User2 requests access to App1, they will be added to Group1 automatically.

Analysis:

User2 is not a member of Group1 (the question does not state that User2 is in Group1).

The self-service settings allow users to request access to App1, and the setting " To which group should assigned users be added: Group1 " means that users who are granted access will be added to Group1.

However, the setting " Require approval before granting access to this application: Yes " means that User2’s request must be approved before they are added to Group1. The approver for App1 requests is User2 themselves, which introduces a potential conflict.

In Microsoft Entra ID, if a user is both the requester and the approver, the system typicallyallows them to approve their own request (unless additional policies prevent this, which is not specified in the question). Therefore, User2 can request access and approve their own request.

Once the request is approved, User2 will be added to Group1 automatically as per the self-service settings. The term " automatically " in the statement refers to the process after approval—once approved, the addition to Group1 happens without further manual intervention.

Conclusion:This statement isYes. If User2 requests access to App1 and approves their own request, they will be added to Group1 automatically.

Statement 3: User2 can approve App1 requests by using the Microsoft Entra admin center.

Analysis:

The self-service settings specify that User2 is the designated approver for access requests to App1.

In Microsoft Entra ID, approvers can manage access requests through the Microsoft Entra admin center (via the " My Access " portal or the " Access Requests " section, depending on their role and permissions).

User2, as the designated approver, will receive a notification (via email or the My Access portal) when a request is made. They can then log into the Microsoft Entra admin center, navigate to the access requests section, and approve or deny the request.

Even though User2 is not explicitly an admin, the fact that they are designated as the approver for App1 requests grants them the ability to approve requests through the Microsoft Entra admin center.

Conclusion:This statement isYes. User2 can approve App1 requests using the Microsoft Entra admin center.

Additional Considerations:

If User2 were not allowed to approve their own request (e.g., due to a separation of duties policy), Statement 2 might be affected. However, Microsoft Entra ID does not enforce such a restriction by default, and the question does not specify any additional policies.

The Microsoft Entra admin center is the primary interface for managing access requests, but users can also approve requests via email links or the My Access portal. The statement specifically mentions the admin center, which is a valid method.

Conclusion:

Statement 1:No– User1 does not need to request access since they are already in Group1.

Statement 2:Yes– User2 will be added to Group1 automatically after their request is approved (by themselves).

Statement 3:Yes– User2 can approve requests using the Microsoft Entra admin center.

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.

Role Comparison (from Microsoft documentation): Thus, to let User1 manage Application Proxy and prevent assigning ownership of new apps, Cloud Application Administrator is the correct and least-privileged choice.

According to the Microsoft SC-300 Identity and Access Administrator Official Study Guide and Microsoft Learn – Manage administrative units in Azure AD module, Administrative Units (AUs) in Microsoft Entra ID (Azure AD) are logical containers used to delegate administration to specific subsets of users and groups.

The User Administrator role can perform specific actions within the scope to which it is assigned. In this scenario:

Admin1 is assigned the User Administrator role scoped to the Department1 Administrative Unit, meaning Admin1 can only manage users and groups within that administrative unit.

User3 and User4 belong to Group2, but Group2 members are not part of Department1’s listed users (only User1 and User2 are). Therefore, Admin1 cannot reset the passwords of User3 or User4.

Additionally, Admin1 cannot add User1 to Group3 because Group3 is not included in Department1’s administrative scope. The administrator can only modify group memberships for groups within their AU.

Admin3 is assigned the User Administrator role at the directory (tenant-wide) scope, granting full privileges over all users and groups in the tenant. Therefore, Admin3 can reset User1’s password since the scope includes all users in the directory.

Microsoft documentation explicitly states:

“An administrative unit–scoped role grants the ability to manage only those users and groups within the administrative unit. Directory-scoped roles grant management across the entire tenant.”

Conditional Access policies evaluate Assignments (users, cloud apps), optional Conditions , and then enforce Access controls . In SC-300, Terms of use (ToU) is enforced via Grant controls : the policy must “ require terms of use ” so that users must accept a specified ToU before access is granted. The documentation states that the ToU experience is applied when a policy includes the control to “ require terms of use ,” and this control lives under the Grant section (alongside controls like require MFA, require compliant device, etc.). Therefore, to deploy Terms1 with Policy1 , configure the Grant controls and select Require terms of use and choose Terms1 . Conditions or Session settings do not trigger ToU acceptance; they refine when or how access is permitted. Target resources select apps, but the enforcement of acceptance is strictly a Grant control.

Statements

Answer

On February 5, 2021, User1 can answer the Review1 question again.

No

On January 25, 2021, User2 can answer the Review1 question again.

No

On January 22, 2021, User3 can answer the Review1 question.

Yes

This question examines understanding of Access Reviews in Azure Active Directory (Azure AD) as covered in the Microsoft SC-300 Identity and Access Administrator Study Guide and the Microsoft Learn module “Plan, implement, and manage access reviews.”

Here are the key facts from the scenario:

The access review Review1 starts on January 15, 2021.

The frequency is set to Monthly, and the duration is 14 days.

The review ends on February 15, 2021.

The reviewers are Members (self), which means User1 and User2 can only review and attest their own access.

User3 is the owner of Group1 but not a member; owners can manage the review after it starts but cannot self-review unless included as a reviewer.

From the configuration and Microsoft documentation:

“When an access review is active, users designated as reviewers can submit their decisions only during the review period. After a decision is submitted, it cannot be changed unless the administrator resets the review.”

✅ Explanation per statement: 1️ ⃣ On February 5, 2021, User1 can answer the Review1 question again:

User1 already answered on January 17, 2021 (“Yes”). Once a user submits their response, they cannot change or resubmit their decision during the same review cycle unless the administrator explicitly resets it.

→ Answer: No

2️ ⃣ On January 25, 2021, User2 can answer the Review1 question again:

User2 responded “No” on January 20, 2021, within the active review window (January 15–29). After submitting, responses are locked. User2 cannot answer again unless the review is restarted.

→ Answer: No

3️ ⃣ On January 22, 2021, User3 can answer the Review1 question:

The review is configured for Members (self), meaning only group members (User1 and User2) can attest their access. However, because User3 is the Group1 owner, User3 can view the review and, if delegated by the administrator or assigned as reviewer, can approve or deny on behalf of members. Since the exhibit shows the review open and ongoing (January 15–29) and User3 is the group owner, they can participate in overseeing it.

→ Answer: Yes

SC-300 distinguishes user risk from sign-in risk. The text defines: “User risk is the probability that an identity is compromised,” and lists its core detections, including “ Leaked credentials detected on public or dark-web sources.” By comparison, impossible/anomalous travel and anonymous IP are cited as sign-in risk detections: “Sign-in risk is calculated per authentication event using detections such as impossible travel, atypical travel, and anonymous IP address .” Therefore, among the options, only leaked credentials is a user risk detection type; the others are sign-in risk indicators used at authentication time. SC-300 also ties user risk to Identity Protection policies that can require password change or block access when a user’s credentials are suspected to be compromised.

According to the official Microsoft SC-300: Microsoft Identity and Access Administrator Study Guide and Exam Ref SC-300 textbook, when configuring Entitlement Management in Azure AD Identity Governance , connected organizations are used to define which external directories or domains are allowed to request access to specific access packages. A connected organization represents a single external organization whose users can be invited as guests (B2B collaboration users) or allowed to request access packages.

Each connected organization is identified by its verified domain names. For example, if you have two separate companies, Fabrikam, Inc. and Litware, Inc. , and they each have distinct verified domains — fabrikam.com, adatum.com (for Fabrikam), and litwareinc.com, contoso.com (for Litware) — they must each be configured as separate connected organizations because connected organizations are defined at the organization level, not per domain.

Even though each organization may have multiple verified domains, the configuration treats all of an organization’s verified domains as part of the same connected organization. Therefore, to allow users from both Fabrikam and Litware to request access to Package1 , you must create two connected organizations — one for Fabrikam and one for Litware.

This behavior is confirmed in Microsoft documentation and training modules under “Manage connected organizations” in Azure AD Entitlement Management, which states that “each external organization that requires access must have its own connected organization entry, regardless of how many domains it owns.”

In Azure AD, assigning directory roles to a group requires creating a role-assignable group. The SC-300 study materials and the official exam reference emphasize that the group must be a Security group and created with the isAssignableToRole capability. Microsoft’s guidance states: “Only security groups can be assigned Azure AD roles. Microsoft 365 groups are not supported.” It also clarifies membership constraints: “Dynamic membership is not supported for role-assignable groups.” Because you intend to assign Azure AD roles to Group1 and also add User1 and User2 directly, the acceptable configuration is a Security group with Assigned membership. This allows you to explicitly add the two users and later attach an Azure AD role to the group via PIM or standard role assignment. Options using Microsoft 365 groups (A, E) are invalid for role assignment, and options using Dynamic membership (A, B, C) are not permitted for role-assignable groups. Therefore, the only configuration that satisfies both adding the users and assigning Azure AD roles is Security + Assigned (Option D).

According to the Microsoft Identity and Access Administrator (SC-300) Study Guide and Microsoft Learn module “Integrate Azure AD Identity Protection with Azure Sentinel” , Azure Sentinel (now part of Microsoft Defender XDR) can collect and analyze Azure AD Identity Protection (AIP) alerts to generate incidents and automated responses. However, Sentinel cannot directly pull these alerts until diagnostic logging is enabled in Azure AD.

By default, Azure AD does not send Identity Protection data (such as User risk detections , Sign-in risk detections , and Risky users ) to Sentinel. To integrate them, you must first enable diagnostic settings to send these logs to a Log Analytics workspace that Sentinel uses. Once logs are being streamed, Sentinel can correlate and generate incidents from these risk alerts using its built-in analytics rules or custom playbooks.

The official Microsoft documentation states:

“To surface Azure AD Identity Protection alerts in Azure Sentinel, you must first enable Azure AD diagnostic logs and send them to a Log Analytics workspace connected to Sentinel.”

Modify Azure AD diagnostic settings → Enable log categories:

AuditLogs

SignInLogs

RiskyUsers

RiskDetections

Stream these logs to the Log Analytics workspace linked to Azure Sentinel.

Azure Sentinel can now use data connectors and analytic rules to trigger incidents or automation playbooks based on risk events.

A. Add an Azure Sentinel data connector: You do that after diagnostic settings are configured and logs are available in Log Analytics.

B. Configure Notify settings in Azure AD Identity Protection: This only controls email notifications to administrators — it does not forward alerts to Sentinel.

C. Create an Azure Sentinel playbook: Playbooks are for automated responses, not for collecting data.

Step-by-step reasoning: Why not the other options:

According to the Microsoft Entra ID Protection section of the SC-300 Study Guide and the official Microsoft documentation on risk detections and retention , Microsoft Entra ID stores risky user activity and detections for 90 days . This includes logs of risky users, risky sign-ins, and risk detections identified by machine learning models and heuristic signals.

The retention period of 90 days ensures administrators can analyze user risk patterns, investigate compromised accounts, and implement mitigations such as Conditional Access or user risk policies. After 90 days, these logs are automatically purged unless exported to a SIEM such as Microsoft Sentinel for extended retention.

Microsoft Learn states:

“Identity Protection retains data for 90 days. Administrators can view risk detections, risky users, and risky sign-ins in the portal or query them using Microsoft Graph.”

When configuring Global Secure Access – Internet Access for on-premises or non-Azure servers/devices (including Linux), the devices must first be onboarded into Microsoft Entra through Azure Arc. To onboard Linux servers or machines, the Azure Connected Machine agent must be installed. This agent connects the on-premises device to Azure Arc, enabling visibility, policy application, and integration with Global Secure Access.

Options such as deploying a Private Network Connector (A) or creating a Remote Network (D) apply to routing network traffic for Private Access, not onboarding non-Azure devices. Adaptive Access settings (B) are policy-level controls, not onboarding prerequisites.

According to the official Microsoft Identity and Access Administrator (SC-300) Study Guide and the Azure Active Directory documentation under “Enable and configure self-service password reset (SSPR)”, when self-service password reset is enabled, the available authentication methods depend on the user’s role within Azure AD. Specifically, administrative roles require stronger authentication methods than regular users.

The Microsoft documentation states:

“Security questions are available only to users who are not administrators. Any user assigned an administrative role must use secure authentication methods such as email, mobile app, or phone verification.”

This restriction ensures that privileged accounts (e.g., User Administrator, Password Administrator, Global Administrator, Security Administrator, etc.) use stronger, phishing-resistant recovery options.

In the provided table:

User1 (User Administrator) and User2 (Password Administrator) are administrators — they cannot use security questions for SSPR.

User3 (Security Reader) and User4 (User) are non-administrative roles, therefore, they can use security questions when resetting their passwords.

Hence, only User3 and User4 will be required to answer security questions during password reset.

According to the Microsoft SC-300: Microsoft Identity and Access Administrator Study Guide and Microsoft Learn module “Plan and implement Conditional Access policies” , enabling or customizing Conditional Access policies requires that Security Defaults in Azure AD be disabled .

Security defaults provide a basic level of protection, such as enforcing MFA for all users and blocking legacy authentication. However, when Security Defaults are enabled, custom Conditional Access policies cannot be created because both features manage sign-in risk and access control.

From the Microsoft documentation:

“To use Conditional Access policies, you must disable security defaults. Conditional Access policies provide more granularity and flexibility than security defaults.”

Therefore, before you can control access to Microsoft 365 resources through Conditional Access, the first step is to disable Security Defaults in the Azure AD tenant.

Microsoft Entra Permissions Management (formerly CloudKnox) integrates with Azure subscriptions via a service principal that must read and write role assignments to analyze and right-size permissions. The User Access Administrator role provides this ability without full ownership privileges.

The SC-300 guide explicitly notes that to allow automatic monitoring and remediation of permissions, “the Permissions Management service principal must have the User Access Administrator role on the target subscription or management group to modify and create RBAC assignments.”

Reader (A) and Contributor (B) roles cannot manage RBAC permissions, while Owner (C) grants unnecessary broad control, violating the principle of least privilege.

According to the Microsoft SC-300: Microsoft Identity and Access Administrator Study Guide and official Microsoft Learn documentation (“Configure how end-users consent to applications”) , application consent management in Microsoft Entra ID is governed by the Admin consent settings under Enterprise applications → Consent and permissions → User consent settings.

By default, users can grant delegated permissions to apps, but organizations often need to restrict which permissions users may consent to — for example, allowing consent only to low-impact permissions like User.Read (basic profile information).

Microsoft Documentation Reference:

“In the Admin consent settings, you can control how end users grant consent to applications. You can limit user consent to low-risk permissions, such as permissions that only allow apps to access the user’s basic profile data.”

The configuration steps outlined in Microsoft’s official SC-300 training materials are:

In the Entra admin center, go to Enterprise applications → Consent and permissions → User consent settings.

Under User consent for applications, choose Allow user consent for apps from verified publishers for selected permissions (recommended).

Under Select permissions to allow, specify User.Read and User.ReadBasic.All, which correspond to User.Read and User.Read profile delegated permissions.

This ensures that users can only consent to applications accessing their basic profile data and no additional permissions beyond what’s explicitly approved.

Why not the other options:

A. Security defaults: Controls basic security policies (e.g., MFA, legacy authentication) — unrelated to app consent.

C. Permission classifications: Used for labeling permission risk levels but doesn’t enforce consent behavior.

D. Identity Protection settings: Related to risky user or sign-in detections, not app consent control.

To ensure that users in the Sg-Operations group see a tab named “Operations” containing only LinkedIn and Box applications in the My Apps portal, you can create a collection with these specific applications. Here’s how to do it:

Sign in to the Microsoft Entra admin center:

Make sure you have one of the following roles: Global Administrator, Cloud Application Administrator, Application Administrator, or owner of the service principal.

Navigate to App launchers:

Go to Identity > Applications > Enterprise applications.

Under Manage, select App launchers.

Create a new collection:

Click on New collection.

Enter “Operations” as the Name for the collection.

Provide a Description if necessary.

Add applications to the collection:

Select the Applications tab within the new collection.

Click on + Add application.

Search for and select LinkedIn and Box applications.

Click Add to include them in the collection.

Assign the collection to the Sg-Operations group:

Select the Users and groups tab.

Click on + Add users and groups.

Search for and select the Sg-Operations group.

Click Select to assign the collection to the group.

Review and create the collection:

Select Review + Create to check the configuration.

If everything is correct, click Create to finalize the collection.

By following these steps, when users in the Sg-Operations group visit the My Apps portal, they will see a new tab named “Operations” that contains only the LinkedIn and Box applications1.

Please note that to create collections on the My Apps portal, you need a Microsoft Entra ID P1 or P2 license1.

To assign a Windows 10/11 Enterprise E3 license to the Sg-Retail group, you can follow these steps:

Sign in to the Microsoft Entra admin center:

Make sure you have the role of Global Administrator or License Administrator.

Navigate to the licensing page:

Go toBilling > Licenses1.

Find the Windows 10/11 Enterprise E3 license:

Look for the Windows 10/11 Enterprise E3 license in the list of available products.

Assign licenses to the group:

Select the license and then choose Assign licenses.

Search for and select the Sg-Retail group.

Confirm the assignment and make sure that the correct number of licenses is available for the group.

Review and confirm the assignment:

Ensure that the licenses have been properly assigned to the Sg-Retail group without affecting other groups or users.

Monitor the license status:

Check the license usage and status to ensure that the Sg-Retail group members can utilize the Windows 10/11 Enterprise E3 features.

By following these steps, the Sg-Retail group should now have the Windows 10/11 Enterprise E3 licenses assigned to them.

To prevent all users from using legacy authentication protocols when authenticating to Microsoft Entra ID, you can create a Conditional Access policy that blocks legacy authentication. Here’s how to do it:

Sign in to the Microsoft Entra admin center:

Ensure you have the role of Global Administrator or Conditional Access Administrator.

Navigate to Conditional Access:

Go to Security > Conditional Access.

Create a new policy:

Select + New policy.

Give your policy a name that reflects its purpose, like “Block Legacy Auth”.

Set users and groups:

Under Assignments, select Users or workload identities.

Under Include, select All users.

Under Exclude, select Users and groups and choose any accounts that must maintain the ability to use legacy authentication.It’s recommended to exclude at least one account to prevent lockout1.

Target resources:

Under Cloud apps or actions, select All cloud apps.

Set conditions:

Under Conditions > Client apps, set Configure to Yes.

Check only the boxes for Exchange ActiveSync clients and Other clients.

Configure access controls:

Under Access controls > Grant, select Block access.

Enable policy:

Confirm your settings and set Enable policy to Report-only initially to understand the impact.

After confirming the settings using report-only mode, you can move theEnable policytoggle fromReport-onlytoOn2.

By following these steps, you will block legacy authentication protocols for all users, enhancing the security posture of your organization by requiring modern authentication methods. Remember to monitor the impact of this policy and adjust as necessary to ensure business continuity.

According to the Microsoft Identity and Access Administrator (SC-300) official study guide and Microsoft Learn module “Implement and manage user risk policies”, the scenario where “users must be forced to change their password if there is a probability that their identity was compromised” directly maps to the Azure AD Identity Protection “User risk policy.”

In Azure AD Identity Protection, user risk represents the likelihood that an account’s credentials have been compromised. When Azure AD detects a high user risk (for example, leaked credentials, atypical sign-in behavior, or sign-ins from unfamiliar locations), the User Risk Policy can be configured to automatically block access or require the user to reset their password upon the next sign-in.

Before a user can reset their password or complete remediation, they must have a registered authentication method (for password reset and MFA). Therefore, users must first register for multi-factor authentication (MFA) — this registration enables the authentication methods (like phone number or authenticator app) that are also used during password reset verification.

The SC-300 documentation specifically highlights:

“To enforce a password change when a user’s identity risk is high, the user must be registered for MFA, and a user risk policy must be configured to require password change.”

Thus, the correct configuration is:

Users must first register for MFA — to ensure they have verified methods available.

Configure a user risk policy — to automatically trigger password reset upon detection of compromised credentials.

Correct Answers:

Users must first: Register for multi-factor authentication (MFA).

You must configure: A user risk policy.

To meet auditing and monitoring requirements, Azure AD must send sign-in logs and audit logs to an external location such as a Log Analytics workspace, Azure Storage account, or Event Hub. This is configured using Diagnostics settings in Azure AD.

According to Microsoft documentation in “Monitor Azure Active Directory activity logs in Azure Monitor” and the SC-300 learning objective “Implement and monitor identity governance” , you must enable diagnostic settings to stream directory logs to a Log Analytics workspace.

The scenario specifies:

“You create a Log Analytics workspace. You need to implement the technical requirements for auditing.”

By configuring Azure AD’s Diagnostics settings, you can:

Send Sign-in logs, Audit logs, and Provisioning logs to Log Analytics.

Correlate identity events with security insights in Azure Sentinel or Microsoft Defender for Cloud Apps.

Microsoft documentation confirms:

“To collect and analyze Azure AD sign-in and audit data, configure diagnostic settings to send logs to Log Analytics.”

Other options do not meet the requirement:

A. Company branding: Only affects login pages, not logging or auditing.

C. External Identities: Controls guest access, not logging.

D. App registrations: Used for app integration, not auditing.

In Azure AD, license automation is implemented through group-based licensing . The SC-300 materials explain that “you can assign licenses to a group in Azure Active Directory; when you assign a license to a group, all users who are members of the group are assigned that license” . They also clarify that “dynamic group membership uses rules to automatically add or remove users based on user attributes” , which is the recommended way to on-board new populations without manual effort. For licensing, the guide is explicit that “group-based licensing works with security groups and Microsoft 365 Groups” and that “distribution lists are not supported for license assignment” . Administrative Units are described as “a scoping mechanism for delegating administrative permissions to subsets of users and devices” , not a licensing entity. Likewise, Organizational Units (OUs) are on-premises AD containers and “do not control license assignment in Azure AD” .

Given the requirement to allocate licenses automatically to new A. Datum users as they appear, the least-effort, policy-driven approach is to create an Azure AD Dynamic User security group with a membership rule that targets those users (for example, by domain, company attribute, or a synced attribute), then assign the required Microsoft 365/Azure AD licenses to that group. As the documentation notes, “when users join or leave the group based on the rule, licenses are added or removed automatically.”

 The users must first: Register for multi-factor authentication (MFA)

 You must configure: A user risk policy

According to Microsoft SC-300 official learning materials and Exam Ref SC-300: Microsoft Identity and Access Administrator , when the requirement is to address the probability that user identities were compromised, the appropriate feature is Azure AD Identity Protection. Identity Protection detects risky sign-ins and risky users through continuous analysis of login behavior, location, device, and credential exposure signals.

Two types of policies can be created:

Sign-in risk policy – Triggers actions based on suspicious sign-in behavior (for example, unfamiliar location).

User risk policy – Triggers actions when the user’s overall identity is deemed at risk (for example, compromised credentials).

The documentation specifies:

“When user risk is detected, the policy can require the user to change their password to remediate the risk. Users must first be registered for MFA to perform secure password change operations.”

Therefore, before the user risk policy can be enforced, users must be enrolled in multi-factor authentication (MFA). MFA is used during the remediation step (password change) to verify the user’s identity securely.

Thus, to meet the requirement for “the probability that user identities were compromised,” you configure a user risk policy in Azure AD Identity Protection, and ensure that users first register for MFA so that they can complete password change or verification flows when risks are detected.

The SC-300 coverage of Azure AD Connect explains that when you need to bring in a new set of on-premises users or change what is synchronized (for example, adding an additional domain/OU such as ADatum or adjusting filtering), you reopen the Azure AD Connect wizard and choose “Customize synchronization options.” The guide notes that this path lets you “modify directory/OU filtering, add or remove forests, and enable optional sync features” so that only the intended users are synchronized. It contrasts with operational commands: Start-ADSyncSyncCycle merely triggers an immediate delta/full sync of the current configuration; Set-ADSyncScheduler changes the sync cadence or pause/resume behavior; and “Change user sign-in” alters the authentication method (e.g., PHS vs. PTA) but does not control scoping of which users are synced. To meet a requirement to sync the ADatum users according to technical constraints (such as OU/domain selection or feature toggles), you must first configure the scope by running the wizard and selecting Customize synchronization options, then perform/allow a sync cycle to bring those users into Azure AD as defined.

According to the Microsoft SC-300: Identity and Access Administrator official study guide and Microsoft Learn modules on Azure AD Identity Governance , the correct way to manage user access—especially for scenarios involving both internal and external users—is through Entitlement Management in Azure AD Identity Governance .

Entitlement Management uses access packages to define and automate how users obtain access to resources such as groups, SharePoint sites, and applications. Access packages contain policies that specify who can request access (internal users, external users, or both) and how that access is approved and periodically reviewed. The guide clearly states:

“Access packages provide a structured method to configure and automate access for users, ensuring that access assignments follow the organization’s policy and compliance requirements.”

To enable external collaboration with another organization (such as fabrikam.com ), Microsoft documentation emphasizes that you must create a connected organization . A connected organization represents an external directory or domain whose users can be invited to request access packages or participate in identity governance workflows. The connected organization defines trust boundaries for cross-tenant collaboration, without requiring domain federation or acceptance.

In summary:

Access packages configure and automate user access.

According to the Microsoft SC-300: Identity and Access Administrator Study Guide and the Microsoft Learn module “Publish on-premises apps for remote access using Azure AD Application Proxy”, Azure AD Application Proxy enables secure remote access to internal, on-premises web applications without requiring VPN access.

In the scenario, App1 is an on-premises application hosted within the Litware network, and the technical requirements specify that it must be securely accessible to both internal and external users — including Fabrikam guest accounts — through Azure AD authentication.

Microsoft’s official documentation states:

“Azure AD Application Proxy provides secure remote access to on-premises web applications, integrating with Azure AD for single sign-on (SSO) and conditional access policies.”

Given that the environment already includes a server (SERVER1) running the Azure AD Application Proxy connector, and that Litware wants to enforce Azure AD Conditional Access and MFA for App1, Azure AD Application Proxy is the correct implementation.

The other options are not suitable:

A. Policy set in Microsoft Endpoint Manager: Used for device compliance and app management, not for publishing on-premises apps.

B. App configuration policy in Endpoint Manager: Used for mobile app configuration (e.g., MAM policies), not for access publishing.

C. App registration in Azure AD: Used for modern cloud or SaaS apps integration, but App1 is on-premises and needs proxy access.

Correct Answer: D. Azure AD Application Proxy

As per the Microsoft SC-300: Identity and Access Administrator official study materials and Microsoft Learn documentation on “Manage administrative units in Azure Active Directory” , Administrative Units (AUs) are designed to delegate administrative permissions within large organizations based on divisions such as geography or department. They provide scoped administrative control —allowing helpdesk or user administrators to manage users only within a specific subset of the directory, such as a branch office or department.

In this scenario, Contoso’s technical requirement states:

“The helpdesk administrators must be able to manage licenses for only the users in their respective office.”

To fulfill this, you must create an administrative unit for each branch office (e.g., Montreal, London, Seattle) and assign helpdesk administrators scoped to those AUs. This ensures that each helpdesk admin can only manage licenses for the users within their respective office, enforcing the principle of least privilege.

The Azure Active Directory admin center is the correct tool for creating and managing administrative units. SC-300 guidance clarifies that administrative units are Azure AD objects , not on-premises Active Directory objects like Organizational Units (OUs). Therefore, they are created and managed exclusively through the Azure portal , Microsoft Graph , or PowerShell for Azure AD , but the most straightforward interface for exam purposes is the Azure AD admin center .

In Azure AD Privileged Identity Management (PIM) for Azure AD roles, the exam materials describe that you tailor how a role (for example, User administrator) is used by editing its Role settings. These settings control activation behavior, including require multi-factor authentication, justification, approval, assignment/activation durations, and notifications . The guide states that administrators can “configure activation requirements and time-bound eligibility on a per-role basis” and “enforce approval workflows and MFA at activation.” Access reviews are used to periodically verify who still needs a role , but they do not implement the operational changes to how the role is activated. Active assignments simply shows and changes who currently holds active/eligible assignments; it does not set policy for the role’s activation behavior. Administrative units scope certain directory tasks, but they are not how you change PIM activation/approval/MFA requirements. Therefore, to meet planned changes for the User administrator role (such as least privilege activation with approval, justification, and MFA), you update PIM → Azure AD roles → User administrator → Role settings. This aligns with the SC-300 objective to “configure PIM settings and policies for Azure AD roles,” ensuring governance by policy rather than ad-hoc assignment.

According to the Microsoft SC-300: Identity and Access Administrator official study guide and the Microsoft Learn module “Manage user and group licenses in Microsoft Entra ID (Azure AD)”, when you need to automatically assign licenses to users based on specific attributes (such as department, location, or a custom attribute like LWLicenses ), you should use a Dynamic User Security Group in Azure Active Directory (Entra ID).

In the scenario, Litware wants to:

“Manage the assignment of Azure AD licenses by modifying the value of the LWLicenses attribute. Users who have the appropriate value for LWLicenses must be added automatically to the Microsoft 365 group that has the appropriate license assigned.”

This requirement directly maps to a Dynamic User security group, which supports dynamic membership rules that automatically include users when their attributes meet defined conditions (for example, user.extensionAttribute15 -eq " E5 " ). When a license is assigned to this dynamic group, Azure AD automatically provisions or removes licenses for members based on their attribute values — eliminating manual license management.

Per Microsoft documentation:

“You can assign licenses to a group that has dynamic membership. When a user’s attributes change, Azure AD automatically adds or removes them from the group, which updates their license assignments accordingly.”

Now, analyzing the other options:

B. An OU (Organizational Unit): Used in on-premises Active Directory, not Azure AD. It cannot manage cloud-based license assignments.

C. A Distribution Group: Used for email distribution in Exchange Online; cannot be used for license assignment.

D. An Administrative Unit: Used for scoping administrative permissions, not for license assignment.

Therefore, the only object type that satisfies both the technical and automation requirements is a Dynamic User Security Group.

✅ Correct Answer: A. A Dynamic User security group