Pass the Microsoft Certified: Identity and Access Administrator Associate SC-300 Questions and answers with ExamsMirror

< User1 can join four additional Windows 10 devices to Azure AD. → No

2️⃣ Admin1 can set “Devices to be Azure AD joined or Azure AD registered require Multi-Factor Authentication” to Yes. → Yes

3️⃣ Admin2 is a local administrator on Device3. → No

This scenario draws from Module: Manage device identities in Azure Active Directory in the Microsoft SC-300 Official Study Guide and Microsoft Learn content.

In the Device Settings, the “Maximum number of devices per user” is configured as 5. User1 already has one Azure AD joined device (Device1) and three Azure AD registered devices (Device2, Device3, Device4). Since both Azure AD joined and Azure AD registered devices count toward the same limit, User1 has already registered 4 devices. This means they can add only one more, not four additional Windows 10 devices. Therefore, the statement is No.

Microsoft documentation states: “The maximum number of devices per user setting applies collectively to all Azure AD-joined and Azure AD-registered devices.”

The Cloud Device Administrator role (Admin1’s role) has the delegated permissions to manage device settings in Azure AD, including enforcing MFA requirements for device registration and join operations. The role allows management of the Azure AD device configuration blade, including toggling settings like MFA for join/register, join limits, and device ownership policies. Therefore, Admin1 can enable the MFA requirement for device join/registration.

As per Microsoft Learn: “Cloud Device Administrator can manage all aspects of device settings, including device join and registration MFA requirements.”

Admin2 holds the Device Administrator role. However, per Microsoft’s documentation, only Azure AD–joined Windows 10 devices grant local administrator rights to users in the Device Administrator role. Azure AD–registered devices (such as Device3) are personal devices that do not have local administrator assignment through Azure AD roles. Since Device3 is Azure AD registered, not joined, Admin2 is not a local admin on it.

Microsoft guidance clarifies: “Users assigned to the Device Administrator role are added as local administrators only on Azure AD–joined devices, not on Azure AD–registered or hybrid devices.”

According to Microsoft Identity Governance documentation and the SC-300 study guide, entitlement management in Azure AD allows you to manage access to resources like SharePoint Online sites, Teams, groups, and applications through access packages. However, before an access package can be created, the administrator must first define a catalog.

A catalog is the logical container that holds all the resources (such as groups, Teams, and SharePoint sites) that can be made available in access packages. The process for entitlement management begins with catalog creation, followed by adding resources, then creating access packages that assign roles for those resources. Therefore, the first step to managing Site1 (SharePoint site) and Team1 (Microsoft Teams team) within entitlement management is to create a catalog and add those resources to it.

This aligns with Microsoft documentation, which states:

“Before creating an access package, you must have a catalog that contains the resources to be made available for assignment.”

According to Microsoft’s official SC-300 Identity and Access Administrator study guide and Microsoft Learn module: Manage emergency access accounts in Azure AD, an emergency access (break-glass) account must always be configured to maintain administrative control during service outages or authentication failures. The study material explicitly emphasizes that these accounts must not rely on on-premises infrastructure or Conditional Access policies that could block sign-ins in an emergency. The recommended configuration is to exclude the emergency account from Conditional Access rules, enable cloud-only authentication, and require strong authentication (MFA) to prevent compromise.

The exam guide states:

“Emergency access accounts should be cloud-only, assigned the Global Administrator role, and configured with multi-factor authentication that does not depend on the organization’s normal identity provider or on-premises systems.”

Options like restricting sign-in to corporate networks (Option C) or requiring Privileged Identity Management activation (Option B) could lock out access if the Azure AD or network is unavailable. Azure Monitor alerts (Option A) help with monitoring but do not prevent sign-in issues. Therefore, the correct answer per Microsoft’s best practice is to enforce MFA for the account to ensure security without relying on on-premises dependencies.

In Microsoft 365 and Azure AD Multi-Factor Authentication (MFA), the supported verification methods include:

Microsoft Authenticator app (notification or verification code)

Phone call

Text message

Hardware token (OATH)

According to the Microsoft SC-300 Study Guide and Microsoft Learn: Plan and deploy Azure AD MFA, the Microsoft Authenticator app offers two modes:

Push notification – requires an active internet connection on the mobile device.

Verification code (time-based one-time password - TOTP) – does not require internet or mobile connectivity. The Authenticator app continuously generates verification codes every 30 seconds locally on the device.

In this scenario, users are working remotely in areas without Wi-Fi or mobile network connectivity. Hence, methods relying on push notifications, SMS, or phone calls are not feasible. The only viable MFA method that works offline is the verification code from the Microsoft Authenticator app, since it functions using the device’s internal clock without external connectivity.

According to the Microsoft SC-300: Identity and Access Administrator Study Guide and Microsoft Learn documentation under “Add and configure custom domains in Microsoft 365”, when an organization acquires a new Microsoft 365 tenant, it starts with a default domain such as contoso.onmicrosoft.com. To use a friendly and company-branded domain like contoso.com for email and user principal names (UPNs), administrators must follow a specific sequence of steps to integrate the custom domain into Azure AD/Microsoft 365.

First, register the custom domain in Azure Active Directory. This action adds contoso.com to your tenant and prepares Microsoft 365 to validate ownership.

After adding the domain, Microsoft 365 provides a TXT record to add to your DNS zone (at your registrar or DNS host). This record proves that your organization owns the domain.

Once the TXT record is published and propagated, return to the Microsoft 365 admin center or use PowerShell to verify the domain. This step confirms domain ownership and completes the domain setup.

Finally, after verification, set contoso.com as the primary domain. Doing this ensures that all newly created users automatically receive user principal names (email addresses) ending in @contoso.com.

Microsoft documentation states:

“After verifying ownership of the custom domain, you can set it as the default (primary) domain for new users in Microsoft 365.”

< Authentication by the domain controller: Pass-through authentication

 SSPR: Password writeback

As per the Microsoft Identity and Access Administrator (SC-300) official study guide and Microsoft Learn documentation for Azure AD Connect, the scenario involves two key requirements:

User sign-ins to Azure AD must be authenticated by an Active Directory domain controller.

In Azure AD hybrid identity configurations, there are three main authentication methods:

Password hash synchronization (PHS): Azure AD verifies the password hash stored in the cloud.

Pass-through authentication (PTA): Authentication requests are passed from Azure AD to on-premises domain controllers using an agent, ensuring that the on-premises AD performs the actual verification.

Federation with AD FS: Redirects authentication to Active Directory Federation Services.

Since the requirement specifies that authentication must occur by an Active Directory domain controller, Pass-through authentication (PTA) is the correct option. This method ensures the user's password validation happens directly against the on-premises domain controller, not the cloud.

Active Directory domain users must be able to use Azure AD self-service password reset (SSPR).

To allow users to reset their passwords in Azure AD and have those changes synchronized back to on-premises Active Directory, the Password writeback feature must be enabled in Azure AD Connect.

This feature securely writes password changes from Azure AD (including SSPR actions) back to the on-premises AD DS environment.

From Microsoft’s official text:

“To enable users to reset their on-premises passwords through Azure AD SSPR, enable the Password writeback feature in Azure AD Connect.”

Therefore, based on Microsoft SC-300 documentation:

Authentication by the domain controller: Pass-through authentication

SSPR: Password writeback

The exhibit shows Password Hash Synchronization (PHS) enabled and Pass-through Authentication (PTA) enabled. The SC-300 materials clarify that when both PTA and PHS are enabled, Azure AD can fall back to PHS if PTA agents become unavailable. The guidance states that PHS can serve as a backup sign-in method to ensure continuity during on-premises connectivity failures. In this scenario, on-premises connectivity to the internet is lost, so PTA agents cannot process sign-ins. Because PHS is enabled, synchronized users can still authenticate in Azure AD using their synced password hashes.

User1 is a cloud-only user and authenticates directly in Azure AD—unaffected by on-premises outages.

User2 is directory-synced; with PTA down, sign-in falls back to PHS, allowing access as long as the hash is present.

User3 is a guest; guests authenticate in their home directory/IdP, independent of your on-premises environment, so they can still sign in.Therefore, during the outage, all three users (User1, User2, and User3) can sign in to Azure AD, satisfying the behavior described in the SC-300 documentation regarding PHS backup for PTA and guest sign-in independence.

According to the Microsoft SC-300 Study Guide, Exam Ref SC-300, and Microsoft Entra (Azure AD B2B collaboration) documentation, when a guest is invited to an Azure AD tenant and the setting “Email one-time passcode for guests” is enabled, Azure AD determines the authentication method based on the guest’s account type.

Here’s how the logic applies:

Guest1 (adatum.com – Azure AD account)

Because adatum.com is an Azure AD-managed domain, Guest1 will authenticate using their own organization’s Azure AD credentials.

The guest sign-in will federate to their home tenant, and therefore no one-time passcode (OTP) is sent.

Guest2 (outlook.com – Microsoft account)

A user with an @outlook.com email has a Microsoft account (MSA).

Microsoft accounts can authenticate directly via Microsoft’s identity system.

Hence, no one-time passcode is sent — the user signs in using their Microsoft account credentials.

Guest3 (gmail.com – Personal Google account)

A @gmail.com address is not a Microsoft account and not linked to any Azure AD tenant by default.

In this case, because the tenant’s setting “Email one-time passcode for guests” is enabled, Azure AD automatically sends a one-time passcode (OTP) to the guest’s email address for authentication.

The Microsoft documentation specifies that the OTP is valid for 30 minutes and is single-use. After expiration, a new code is issued upon the next authentication attempt.

This is confirmed in Microsoft’s official Entra ID documentation:

“When the Email one-time passcode for guests setting is enabled, guests who do not have an Azure AD or Microsoft account will authenticate using a one-time passcode that is valid for 30 minutes.”

 User1: Key Vault Crypto Officer

 User2: Key Vault Certificates Officer

As detailed in Microsoft documentation and the Exam Ref SC-300: Microsoft Identity and Access Administrator, Azure Key Vault provides role-based access control (RBAC) to manage keys, secrets, and certificates independently. The built-in roles are designed with the principle of least privilege — granting users only the permissions necessary to perform their tasks.

According to the Microsoft Learn module “Manage access to Key Vault using Azure RBAC”, the relevant built-in roles are:

Key Vault Crypto Officer — This role allows users to manage cryptographic keys in a key vault. Specifically, the Crypto Officer can create, import, delete, and manage keys, as well as perform cryptographic operations such as encrypt, decrypt, sign, and verify. This aligns perfectly with the requirement that User1 must manage and create keys in Vault1.

Key Vault Certificates Officer — This role allows a user to manage and retrieve certificates within a key vault. It provides access to read, import, and delete certificates but not to manage or create keys or secrets. This satisfies the requirement that User2 must access a certificate stored in Vault1.

The Exam Ref SC-300 emphasizes that the least privilege principle requires assigning users the lowest possible role that meets their operational needs. Therefore, assigning Key Vault Crypto Officer to User1 and Key Vault Certificates Officer to User2 ensures compliance, minimal access exposure, and operational

As documented in Microsoft’s App governance for Microsoft 365 guidance, App Governance is a security and compliance add-on that provides visibility and policy-based controls over OAuth-enabled applications integrated with Microsoft 365. Once you purchase and assign the app governance license, the integration and management of this feature are performed through the Microsoft 365 Defender portal.

In the Defender portal, administrators navigate to App governance under the Permissions & Apps section to enable integration, view insights, and configure policies. Microsoft documentation states:

“App governance capabilities are surfaced in the Microsoft 365 Defender portal (https://security.microsoft.com) where you can monitor, alert, and remediate risky app behaviors connected to Microsoft 365 data.”

Therefore, the integration and monitoring are managed only in Microsoft 365 Defender, not in Azure AD, Purview, or Defender for Cloud Apps.