Microsoft SC-300

Admins and users in the Guest Inviter role can invite: Yes. In Azure AD External Identities, the “Guest invite settings” include an option that explicitly allows administrators and users assigned the Guest Inviter role to invite external users. This is a common baseline configuration because it limits who can create guest accounts while still enabling delegated invitations without requiring full admin rights. Why not No? If this were set to No, only admins (or potentially no one, depending on the configuration) could invite, and the Guest Inviter role would be ineffective for invitations. In most exam exhibits for this question type, the setting is enabled, and the presence of the Guest Inviter role in the statement implies it is permitted. Practical impact: With this enabled, a user sharing from SharePoint can trigger a B2B invitation only if they are an admin or have the Guest Inviter role (or if other invite settings also allow members/guests).

Members can invite: No. This setting controls whether standard member users (regular internal users) can invite external guests into the directory. When set to No, only admins and/or users in the Guest Inviter role can invite. This is a common security posture aligned with least privilege (Azure Well-Architected Framework: Security pillar), because uncontrolled guest invitations can increase risk (data oversharing, unmanaged external identities). Why not Yes? If members could invite, then any internal user could create guest accounts simply by sharing content externally, which is often restricted in regulated environments. The question’s scenario focuses on guest invite settings and passcodes, and typically the exhibit for such questions shows members are not allowed to invite. Operational note: Even if SharePoint sharing is enabled, Azure AD guest invitation policy can still block the creation of new guest objects by members, preventing external sharing that relies on new guest invitations.

Guests can invite: No. This setting determines whether existing guest users can invite additional external users. In most organizations, this is disabled to prevent “viral” growth of external access and to keep governance controls (access reviews, entitlement management, sponsorship) manageable. Why not Yes? Allowing guests to invite other guests can create a chain of external access that is harder to audit and govern, and it can bypass intended business approval processes. For SC-300, the expected best practice is that guests should not be able to invite unless there is a specific collaboration requirement and compensating controls. Effect on the scenario: This setting doesn’t directly decide who gets an email passcode, but it affects whether certain users are even able to initiate invitations/sharing that creates new guest accounts.

When enabled, Email one-time passcode (OTP) lets Azure AD authenticate B2B guest users who do not have another supported identity provider. It is intended for users who cannot sign in with an Azure AD account, a federated identity, or a Microsoft account. Therefore, an Outlook.com user would normally authenticate with their Microsoft account rather than receive an email OTP. This setting being enabled is still correctly identified as Yes, but it does not mean every external user will be sent a passcode.

Enable guest self-service sign up via user flows (Preview): No. This setting relates to Azure AD External Identities self-service sign-up using user flows (a capability associated with External Identities/B2C-style experiences). It is separate from standard B2B invitation and SharePoint sharing flows. In many Microsoft 365 tenant configurations, this preview feature is not enabled by default and is often shown as disabled in exam exhibits. Why not Yes? Enabling it would allow certain self-service sign-up experiences for external users through user flows, but it is not required for SharePoint external sharing invitations. The question’s focus is on guest invite settings and Email OTP, not on building user flows. Exam tip: Don’t confuse “self-service sign-up via user flows” with “Email one-time passcode.” OTP is an authentication fallback for B2B; user flows are a separate external identity onboarding mechanism.

Yes. User1@outlook.com is in the Outlook.com domain, which is explicitly included in the tenant’s Collaboration restrictions allow list ("Allow invitations only to the specified domains"). Therefore, inviting User1 is permitted and the guest object can exist in the directory even if the user has not yet redeemed (accepted) the invitation. The important distinction is between (1) being invited/created as a Guest user in the directory and (2) redeeming the invitation. A guest can appear with userType=Guest before acceptance; however, until redemption, the user typically cannot complete sign-in to access assigned resources. The restriction setting does not prevent the guest object from existing for an allowed domain; it only blocks invitations to non-allowed domains.

No. With "Allow invitations only to the specified domains" and only Outlook.com listed, invitations to fabrikam.com are not allowed. That means a new invitation to User2@fabrikam.com should be blocked, and the user should not be able to newly accept an invitation under this restriction. In many exam scenarios, if a fabrikam.com guest is described as already accepted, that would only be possible if the guest was invited and redeemed before the restriction was put in place, or if another mechanism created the guest. But based on the configuration shown and the intent of the question, fabrikam.com is not an allowed domain for invitations, so the statement as presented should be treated as not true under the current restrictions.

Pass. The image indicates the tenant is set to the most restrictive option: "Allow invitations only to the specified domains" and the specified/target domain shown is Outlook.com. This is the critical control that drives the rest of the answers: Outlook.com addresses can be invited; other domains cannot be invited. On SC-300, when you see this setting, immediately map it to: allowed domains = can invite; all other domains = invitation blocked. Then evaluate each user’s email domain and whether they are a new invite versus an already-existing guest. That approach is exactly what is needed to answer the remaining sub-questions.

Yes. Because User1@outlook.com is in the allowed domain list, the invitation can be sent and the user can redeem (accept) it. After acceptance, the guest can authenticate in your tenant and, if assigned/authorized, access the enterprise application. Collaboration restrictions do not prevent acceptance for allowed domains; they are designed to prevent inviting (and typically redeeming) users from non-approved domains. Assuming the enterprise application assignment (or group assignment) is in place and there are no additional blocks (Conditional Access, user disabled, etc.), User1 should be able to accept and then gain access.

No. The correct answer is No only if User2 was never able to become a valid redeemed guest under the scenario being evaluated. However, collaboration restrictions primarily control whether new B2B invitations can be sent to specific domains; they do not automatically revoke access for guests who already exist in the directory and have already redeemed an invitation. If User2@fabrikam.com had already accepted the invitation before the restriction was configured, User2 could typically still access the enterprise application if permissions remained assigned. Therefore, the reason should not be that the current allow list by itself blocks an already accepted guest from signing in. The explanation must distinguish between blocking new invitations and revoking existing guest access.

No. The External collaboration setting is configured to allow invitations only to the specified domains, and the only allowed domain shown is Outlook.com. Therefore, only guests with an Outlook.com email address can be newly invited and redeem invitations. Because this statement is about User3 rather than User1, and User3 is not the Outlook.com guest referenced in the scenario, User3 would not be able to accept the invitation unless User3's domain were also on the allow list. The current explanation is incorrect because it answers for User1 instead of User3 and does not evaluate User3's eligibility under the restriction.

Pass. The correct sequence to gain global admin in a self-service (unmanaged/viral) tenant is the admin takeover process: 1) Create a self-signed user account in the Azure AD tenant (a user in the unmanaged tenant using contoso.com). 2) Sign in to the Microsoft 365 admin center with that user. 3) Respond to the “Become the admin” message (this initiates takeover and prompts for domain verification). 4) Create a TXT record in the contoso.com DNS zone to prove domain ownership and complete verification. Why other listed actions are wrong/not needed: “Add the domain name” in the admin center is typically part of managed tenant setup, but in takeover the domain is already present in the tenant; the critical step is verifying ownership via the TXT record prompted by the takeover flow. “Remove the domain name” is unrelated and would not grant admin rights; it could also disrupt users/services.

The Groups exhibit shows that Department1 contains Group1 and Group2. This matters because an administrative unit-scoped User Administrator can manage groups that are members of that administrative unit. The image is not asking a meta Pass/Fail question in the original exam context; it is simply supporting evidence for the later statements. Therefore, the current treatment as a meta-check is incorrect.

The Group2 exhibit shows that User3 and User4 are direct members of Group2. This is important because membership in a group that belongs to an administrative unit does not automatically make those users members of the administrative unit itself. The image is supporting context for evaluating Admin1's scope, not a separate Pass/Fail knowledge check. Therefore, the current treatment as a meta-check is incorrect.

Admin1 has the User Administrator role scoped only to the Department1 administrative unit. Department1 contains User1 and User2 as users, but User3 and User4 appear only as members of Group2 and are not shown as members of the administrative unit. Administrative unit membership is separate from group membership, so being inside Group2 does not place User3 or User4 in Department1. Therefore, Admin1 cannot reset the passwords of User3 and User4, so the correct answer is No.

Admin1 is a User Administrator scoped to Department1, and Group2 is a group contained in that administrative unit. A User Administrator scoped to an administrative unit can manage the groups within that unit, including updating membership for those groups. User1 is also in Department1, so both the target group and the user being added are within the administrative unit's scope. Therefore, Admin1 can add User1 to Group2, so the correct answer is Yes.

Admin2 has the User Administrator role with Directory scope, which applies across the entire Azure AD tenant. Directory-scoped assignments are not limited by administrative unit boundaries. Since User1 is a normal user in the tenant and there is no indication of a protected privileged role, Admin2 can reset User1's password. Therefore, the correct answer is Yes.

A is correct because, with the configuration shown, the evaluated passwords will be blocked by Azure AD Password Protection. Why they are blocked: - "Pr0jectlitw@re" contains two banned terms with common substitutions: "Pr0ject" matches the banned word "project" (0→o, case-insensitive), and "litw@re" matches "Litware" (@→a). Azure AD Password Protection’s fuzzy matching is designed to catch exactly these patterns. - "T@ilw1nd" is a leet variation of "Tailwind" (@→a, 1→i). This is a close match to the banned term "Tailwind". - "C0nt0s0" is a leet variation of "Contoso" (0→o). This is a close match to the banned term "Contoso". Why "Fail" is wrong: the exhibit clearly shows Enforce custom list = Yes and Mode = Enforced, so these passwords are not merely logged; they are actively rejected.

The image shows the key enterprise application settings for App1: Enabled for users to sign-in is set to Yes, User assignment required is set to No, and Visible to users is set to Yes. These settings are sufficient to determine both who can access the app and whether it appears in user-facing portals. Because the screenshot clearly provides the needed configuration values, the item is answerable from the exhibit alone. The selected response is therefore appropriate.

All users can access App1 from the homepage URL. Reasoning: In an Enterprise application, “User assignment required?” determines whether users must be explicitly assigned to the app to sign in. The exhibit shows User assignment required = No. That means any user in the tenant can attempt to access/sign in to the application (for example by navigating directly to the homepage URL or initiating an OAuth/SAML sign-in), assuming no other restrictions (Conditional Access, app roles enforced by the app itself, etc.). Why the other options are wrong: - No one: incorrect because sign-in is enabled and assignment is not required. - Only Owners: owners manage the app registration/enterprise app but are not the only users who can sign in when assignment isn’t required. - Only Users and groups: that would be true only if User assignment required were set to Yes.

App1 will appear in the Microsoft Office 365 app launcher for all users. Reasoning: App tiles appear for users who both (1) have access to the app and (2) the app is set to be visible. The exhibit shows Visible to users? = Yes, which allows the app to be shown in user-facing portals. Because User assignment required = No, all users effectively have access without needing explicit assignment. Therefore, the app can appear for all users in the Microsoft 365 app launcher (and similarly in My Apps). Why the other options are wrong: - No one: would be true if Visible to users were No or if sign-in were disabled. - Only Owners: ownership doesn’t control launcher visibility. - Only Users and groups: would apply if assignment were required; it is not in this configuration.

Yes. A group with Membership type Assigned supports direct, manual membership management. That means you can add eligible directory objects as members (subject to the group’s type constraints). For a Security group with Assigned membership, you can add users, devices, and (importantly for this scenario) other security groups as nested members. This is commonly used to simplify access assignments (for example, assigning a nested security group to an Azure role or an enterprise application). Why not “No”: “No” would be correct only if the membership type were Dynamic User or Dynamic Device, because dynamic groups do not allow manual additions/removals—membership is computed from the dynamic rule. Since Group1 is explicitly stated as Assigned, it is eligible to be added where group nesting is supported (for example, into another Security group).

No. A group with Membership type Dynamic User cannot be added as a member to another group in the way an assigned security group can be nested. Dynamic groups are rule-driven containers: their membership is calculated automatically based on user attributes, and they are not intended to be used as nested members in other groups. Additionally, dynamic groups have restrictions around what they can contain and how they are managed: you cannot manually add members to a dynamic group, and you generally cannot use a dynamic group itself as a “member object” inside another group to create nested membership. For exam purposes, treat dynamic groups as non-nestable membership sources. Therefore, selecting “No” reflects the platform constraint and avoids assuming you can nest a dynamic user group inside another group to indirectly grant access.

No. A group with Membership type Dynamic Device is also rule-based and is not used as a nested member inside other groups. Dynamic Device groups are evaluated based on device attributes (for example, deviceOSType, deviceOwnership, or extension attributes) and automatically include devices that match the rule. Because the group’s membership is computed, Azure AD does not support treating the dynamic device group itself as a member object to be added into another group for nesting scenarios. Also, even if a target group supports devices as members, that is different from adding a device object directly; it does not imply you can add a dynamic device group as a nested group. So the correct choice is “No” to reflect that dynamic groups are not eligible for nesting as members.

Yes. Group4 has Membership type Assigned, which means it is a manually managed group and can be added as a member where the target group type supports group nesting. In Azure AD, assigned Security groups are the primary group type that supports nesting (security group inside another security group). This is a common operational pattern: you create role-based or application-based security groups and then nest departmental or functional security groups inside them to reduce administrative effort and align with least privilege. Why not “No”: “No” would apply if Group4 were dynamic (user/device) or if the target group type did not support groups as members (for example, Microsoft 365 groups). But the question here is only whether an Assigned group is eligible in principle—so “Yes” is correct.

GroupA is a Security group with Assigned membership. Security groups support adding users and (nested) security groups as members. From the options provided, you can add: - User1 (a user object) - Group1 (Assigned security group) - Group4 (Assigned security group) You cannot add Group2 (Dynamic User) or Group3 (Dynamic Device) as nested members because dynamic groups are rule-driven and not supported as nested group members. Therefore, the correct set is “User1, Group1, and Group4 only” (Option D). Other options are wrong because they include Group2 and/or Group3, which are dynamic groups and not eligible to be added as members to GroupA.

GroupB is a Microsoft 365 group with Assigned membership. Microsoft 365 groups are collaboration groups (used by Teams, Outlook groups, SharePoint, Planner) and do not support adding other groups as members (no nested groups). Membership is intended to be individual users (and potentially guests), not groups. So, from the candidate objects listed (User1 and Group1/Group2/Group3/Group4), only User1 can be added directly as a member. Even though Group1 and Group4 are Assigned, and even though GroupA (security) would allow nesting, Microsoft 365 groups do not. Hence the correct answer is “User1 only” (Option A). All other options are incorrect because they include one or more groups as members of a Microsoft 365 group, which is not supported.

Yes. The exhibit’s PIM settings for the User administrator role show the Activation maximum duration configured as 8 hours. In PIM, this value sets the maximum time an eligible activation can remain active before it automatically expires and the user loses the elevated permissions. Why others are wrong: Selecting “No” would imply the configured maximum duration is something other than 8 hours (for example 1 hour, 4 hours, or 24 hours), which would contradict the displayed role settings. Also note that this is not related to assignment expiration (eligible/active assignment duration); it is specifically the activation session duration for an eligible user after they activate the role.

Yes. The exhibit indicates “Require justification on activation” is enabled. This means when an eligible user activates the User administrator role, they must enter a business justification (free text) as part of the activation workflow. Why others are wrong: “No” would only be correct if the setting were disabled. Justification is an activation-time control (JIT elevation) and is separate from “Require justification on active assignment,” which applies when an admin assigns the role as Active. Exams often try to confuse these two similarly named settings—ensure you’re reading the Activation section, not the Assignment section.

Yes. The statement says “Require ticket information on activation is No.” This matches the exhibit where ticketing is not required during activation. In PIM, ticket information typically integrates with ITSM processes (for example, requiring a change/request ticket number) to support auditability. Why others are wrong: Choosing “No” would mean ticket information is required (set to Yes), which would force users to provide ticket details at activation time. Also, ticket requirement is independent of justification and MFA; you can require any combination of these controls.

Yes. The exhibit shows “On activation, require Azure MFA” enabled. This means an eligible user must complete MFA as part of the activation process (or have a valid MFA claim per Conditional Access/session state) before the role becomes active. Why others are wrong: “No” would only be correct if MFA were not required for activation. Also, this setting is different from “Require Azure Multi-Factor Authentication on active assignment,” which applies to making an assignment Active. Here, it’s explicitly an activation-time requirement for eligible users.

Yes. The exhibit indicates “Require approval to activate” is enabled. With this setting, an eligible user’s activation request does not immediately grant the role; it enters a pending state until an approver approves it. Why others are wrong: “No” would mean self-activation is allowed (subject to other controls like MFA/justification). Approval is a strong governance control used for high-impact roles and aligns with least privilege and separation of duties.

No. If “Require approval to activate” is set to Yes, then approvers must be configured (one or more users or groups). The exhibit shows approvers are configured (not None). In PIM, an approval workflow cannot function without approvers. Why others are wrong: Answering “Yes” would imply the approver list is empty. That would be inconsistent with a working approval requirement and inconsistent with the exhibit. In real deployments, if approvers were truly none, activation requests would be blocked because there would be nobody to approve them.

Yes. The exhibit shows “Allow permanent eligible assignment” is set to No. That means when assigning the User administrator role as Eligible, the assignment must have an end date/time; it cannot be indefinite. Why others are wrong: “No” would indicate permanent eligible assignments are allowed, which would weaken governance (users could remain eligible forever). Disallowing permanent eligibility is a common identity governance control to ensure periodic review and to reduce standing privilege exposure over time.

Yes. The exhibit indicates eligible assignments expire after 15 days. Because permanent eligible assignment is not allowed, PIM enforces a time-bound eligible assignment duration, and the configured value is 15 days. Why others are wrong: “No” would mean the eligible assignment expiration is not 15 days (for example, 30 days or 1 year). Also, do not confuse this with activation maximum duration (8 hours). Eligible assignment duration controls how long the user remains eligible to activate; activation duration controls how long the role stays active after activation.

Yes. The exhibit shows “Allow permanent active assignment” is set to No. This means you cannot assign the User administrator role as Active indefinitely; any active assignment must be time-bound. Why others are wrong: “No” would imply permanent active assignments are allowed, which would create standing privilege and is generally discouraged for privileged roles. PIM is designed to minimize always-on access; time-bound active assignments are a governance mechanism when active assignment is necessary (for example, during a project).

Yes. The exhibit shows active assignments expire after 1 month. Since permanent active assignment is not allowed, PIM requires an expiration, and the configured duration is one month. Why others are wrong: “No” would mean the active assignment expiration is different. Also, this is not the same as the activation duration (8 hours). Active assignment expiration applies to users assigned as Active (standing role membership for a limited period), not to eligible users activating JIT.

Yes. The statement says “Require Azure Multi-Factor Authentication on active assignment is No,” and the exhibit shows that MFA is not required when creating an active assignment. This setting governs the administrative action of assigning the role as Active. Why others are wrong: “No” would mean MFA is required for active assignment. Note the nuance: even if MFA is not required for the assignment action, you can still require MFA for activation (which is enabled here). These are separate controls in PIM.

Yes. The exhibit indicates “Require justification on active assignment” is disabled (No). That means when an admin assigns the User administrator role as Active, they are not forced by PIM to enter a justification. Why others are wrong: “No” would imply justification is required for active assignment. Again, don’t confuse this with “Require justification on activation,” which is enabled and applies to eligible users activating the role.

8 hours. The exhibit requires Azure MFA on activation and sets the activation maximum duration to 8 hours. Practically, an eligible user must perform MFA each time they activate the role, and each activation can last up to 8 hours. After 8 hours, the activation expires and the user must re-activate (and therefore satisfy MFA again) to regain the role. Why the other options are wrong: 15 days and 1 month are assignment expiration values (eligible and active assignment lifetimes). They do not define how frequently MFA is performed. MFA is tied to activation events (and potentially Conditional Access session policies), not to the eligible/active assignment expiration timers.

When 'Require approval to activate' is enabled in PIM, activation must be approved by the users or groups listed in the Approvers setting for that role. The exhibit indicates that the approver configured is a permanently assigned User administrator, so that is the required approver before activation can complete. Global Administrator or Privileged Role Administrator can manage PIM settings, but they are not automatically the activation approvers unless explicitly configured. Therefore, the approval depends on the configured approver list, not on general administrative privilege alone.

Correct answer: A. Directory Extensions. Directory Extensions in Azure AD Connect is the setting used to synchronize additional on-premises AD DS attributes to Azure AD as extension attributes. This is commonly required when licensing (or other cloud controls) must be driven by an attribute that is not part of the default sync set. Once synchronized, those attributes can be used in Azure AD for dynamic group rules, access decisions, and governance processes. Why not B (Domain Filtering): Domain filtering controls which on-premises AD domains are included in synchronization. It does not control which attributes are synchronized, so it won’t help meet licensing requirements based on user properties. Why not C (Optional Features): Optional features enable specific hybrid capabilities (for example, password writeback, group writeback, device writeback, Exchange hybrid). They are not the mechanism for adding/syncing extra user attributes needed for dynamic licensing logic.

Correct answer: C. An Azure Active Directory group that has the Dynamic User membership type. Dynamic User groups are the best choice when licenses must be assigned automatically based on user attributes or rules. Azure AD group-based licensing supports assigning licenses to security groups and Microsoft 365 groups that contain users directly, and dynamic user groups are commonly used to automate that membership. Option A is incorrect because nested groups are not processed for group-based licensing. Option B is not inherently invalid for licensing, but it requires manual membership management and would not satisfy a requirement for automatic, attribute-based assignment as effectively as a Dynamic User group.

Assigning users to App1 is done on the enterprise application (service principal). Application Administrator and Cloud Application Administrator can manage enterprise applications, including user and group assignment, so Admin1 and Admin3 can perform this task. Application Developer can manage application registrations they create and, for applications they own, can manage aspects of the corresponding enterprise application, including assignment; therefore Admin2 is also included. User1 has no admin role and is not stated to be an owner of App1, so User1 cannot assign users to App1.

Registering App2 in Azure AD refers to creating an app registration (an application object) in the tenant. The question explicitly states the tenant has the default App registrations settings. By default, Microsoft Entra ID allows non-admin users to register applications (“Users can register applications” = Yes). With that default setting, any authenticated user can create an app registration, not only administrators. That means Admin1, Admin2, Admin3, and User1 can all register App2. Options that limit registration to only Admin1 and/or Admin3 would be correct only if the tenant setting were changed to restrict app registrations to admins, or if additional governance controls were applied. Since the question says default settings, the broadest option is correct.