The retention period for Azure Active Directory (Azure AD) sign-in logs is dependent on the Azure AD license. For tenants with Azure AD Premium P1 or P2 licenses, which are typically assumed for the feature scope of the SC-300 exam, the sign-in logs are retained for 30 days. For tenants with an Azure AD Free license, the retention period is 7 days. Since 7 days is not an option and 30 days corresponds to the premium licenses that enable comprehensive log review, it is the correct answer. Longer retention requires exporting the logs to another service like Azure Monitor or a storage account.

A. 14 days: This is not a standard retention period for any Azure AD activity logs.

C. 90 days: This is the retention period for Audit logs in Azure AD Premium P1/P2 tenants, not for sign-in logs.

D. 365 days: This retention period is not available natively within Azure AD. It can be achieved by archiving logs to an Azure storage account, but it is not the default duration Azure AD stores the data.

1. Microsoft Learn. "How long does Azure AD store reporting data?". Azure Active Directory documentation. Accessed October 2023. In the "Activity logs" section

the table explicitly states that for the "Sign-ins" report type with an "Azure AD P1 or P2" license

the retention period is "30 Days".

Reference: https://learn.microsoft.com/en-us/azure/active-directory/reports-monitoring/reference-reports-data-retention (See the table under the "Activity logs" section).

2. Microsoft Learn. "What are Azure Active Directory reports?". Azure Active Directory documentation. Accessed October 2023. This document discusses the different reports available and notes that "If you have an Azure AD Premium P1 or Azure AD P2 license

you can retain the audit logs and sign-in logs for up to 30 days."

Reference: https://learn.microsoft.com/en-us/azure/active-directory/reports-monitoring/overview-reports#what-azure-ad-license-do-you-need-to-access-activity-logs (See the "Activity log retention" section).

User1 is a cloud-only account, so authentication is performed entirely in Azure AD and never depends on the on-premises network. The Azure AD Connect settings in the exhibit show Password Hash Synchronization (PHS) enabled. User3 is a synchronized account whose password hash has been copied to Azure AD; authentication is therefore executed in Azure AD and still succeeds when the on-premises environment is offline. User2 is configured for Pass-through Authentication (PTA). PTA requires Azure AD to contact an on-premises Authentication Agent to validate the password against Active Directory. Because the on-premises network has lost Internet connectivity, the agent cannot be reached and User2’s sign-in fails.

B User3 (PHS) can also authenticate; limiting the answer to User1 is incomplete. C User2 uses PTA; without Internet connectivity the authentication agent is unreachable, so User2 cannot sign in. D User2 cannot authenticate for the reason above; including User2 makes the option wrong.

1. Microsoft, “Choose the right authentication method for your hybrid identity,” section “Password hash synchronization sign-in flow,” para. 1-3 (docs.microsoft.com/azure/active-directory/hybrid/choose-ad-authn).

2. Microsoft, “How pass-through authentication works,” section “Sign-in flow,” para. 4 (docs.microsoft.com/azure/active-directory/hybrid/how-to-connect-pta).

3. Microsoft, “Password hash synchronization with Azure AD Connect,” Overview, para. 2-3 (docs.microsoft.com/azure/active-directory/hybrid/whatis-phs).

The scenario requires an MFA method that works when the user's mobile phone has no internet or cellular connectivity. The Microsoft Authenticator app can generate time-based one-time passcodes (TOTP), which are displayed as a "verification code." This functionality works entirely offline on the mobile device. The user can open the app on their disconnected phone, retrieve the 6 or 8-digit code, and manually enter it into the sign-in prompt on their internet-connected laptop to satisfy the MFA requirement. This is the only method listed that accommodates the specified connectivity constraints.

A. A notification through the Microsoft Authenticator app requires the phone to have an active internet connection (Wi-Fi or cellular) to receive the push notification from Microsoft Entra ID.

B. Email is a method primarily used for Self-Service Password Reset (SSPR), not as a primary authentication method for an MFA challenge during a sign-in event.

C. Security questions are a knowledge-based proof used for Self-Service Password Reset (SSPR) and are not considered a valid "possession" factor for multi-factor authentication.

1. Microsoft Learn. "Authentication and verification methods available in Microsoft Entra ID." Microsoft Entra Documentation. Under the table "Method

" the row for "Microsoft Authenticator verification code" lists its use case for "MFA and SSPR" and notes it is a one-time passcode (OATH). In contrast

"Email address" and "Security questions" are listed for SSPR only.

Reference: learn.microsoft.com/en-us/azure/active-directory/authentication/concept-authentication-methods

Section: "Methods and their use cases".

2. Microsoft Learn. "How to use the Microsoft Authenticator app." Microsoft Entra Documentation. This document explains the different modes of the app. The section "Sign in with a code from the app" explicitly states: "If you can't get a notification to your device

for whatever reason

you can still sign in using a one-time password (OTP) code in the Microsoft Authenticator app." This confirms its offline capability.

Reference: learn.microsoft.com/en-us/azure/active-directory/authentication/how-to-use-microsoft-authenticator-app

Section: "Sign in with a code from the app".

3. Microsoft Learn. "How Microsoft Entra multifactor authentication works." Microsoft Entra Documentation. This document outlines the available verification methods. It distinguishes between the push notification and the verification code from the Microsoft Authenticator app

implicitly highlighting that they operate under different connectivity requirements.

Reference: learn.microsoft.com/en-us/azure/active-directory/authentication/concept-mfa-howitworks

Section: "Available verification methods".

Security defaults and Conditional Access policies are mutually exclusive. To enable security defaults in an Azure AD tenant, all existing Conditional Access policies must first be disabled or deleted. The presence of CAPolicy1 prevents anyone, regardless of their administrative role, from enabling security defaults. Therefore, the first and necessary action to achieve the goal is to remove this blocking policy. After the policy is deleted, an administrator with the appropriate permissions (such as Security Administrator or Global Administrator) can then proceed to enable security defaults.

A. Configure Identity Governance. Identity Governance features, such as access packages and access reviews, are unrelated to the configuration of tenant-wide security defaults. B. Delete Package1. Package1 is an access package within Identity Governance. Deleting it has no impact on the ability to enable or disable security defaults. D. Assign Admin1 the Authentication administrator role for Au1. This is incorrect for two reasons: the role and the scope. The Authentication Administrator role does not have permissions to manage security defaults, and a role scoped to an administrative unit (Au1) cannot manage tenant-wide settings.

1. Microsoft Entra documentation, "Security defaults in Microsoft Entra ID": This document explicitly states the relationship between security defaults and Conditional Access.

Section: "Disabling security defaults"

Content: "If you have Conditional Access policies enabled in your directory, security defaults will be unavailable to you... To enable security defaults, you must disable all Conditional Access policies." This supports the correct answer (C).

2. Microsoft Entra documentation, "Microsoft Entra built-in roles": This source details the permissions for different administrative roles.

Section: "Security Administrator"

Content: Lists "manage security defaults" as a permission for this role.

Section: "Authentication Administrator"

Content: Permissions are limited to setting or resetting authentication methods for users. It does not include managing security defaults, which invalidates option (D).

3. Microsoft Entra documentation, "Administrative units in Microsoft Entra ID": This document explains the purpose and limitations of administrative units.

Section: "Administrative unit management scenarios"

Content: It clarifies that AUs are for delegating permissions over a subset of directory objects (users, groups, devices). Tenant-wide settings like security defaults are managed at the directory level, not within an AU scope. This further invalidates the scoping in option (D).

The scenario requires removing Microsoft Office 365 E3 licenses that were assigned directly to individual users. The most efficient way to perform this bulk operation is by using a PowerShell script. The Set-MsolUserLicense cmdlet, part of the legacy MSOnline (Azure AD V1) PowerShell module, is specifically designed to modify license assignments for user accounts. It includes a -RemoveLicenses parameter that allows an administrator to specify which license SKU to remove. By scripting this command to iterate through the 2,500 users, the directly assigned E3 licenses can be removed with the least administrative effort, fulfilling the question's requirement.

A. the Set-MsolProductKey cmdlet: This is not a valid or recognized PowerShell cmdlet for managing Microsoft 365 or Azure AD licenses.

B. the Update-MgGroup cmdlet: This cmdlet modifies the properties of a group, including its license assignments. It cannot be used to remove licenses that were assigned directly to individual users.

D. the Update-MgUser cmdlet: This is a general-purpose cmdlet from the Microsoft Graph PowerShell SDK for updating user object properties. The more specific and direct cmdlet for managing licenses is Set-MsolUserLicense (or its modern equivalent, Set-MgUserLicense).

1. Microsoft Learn. (n.d.). Set-MsolUserLicense. Microsoft PowerShell Documentation. Retrieved from https://learn.microsoft.com/en-us/powershell/module/msonline/set-msoluserlicense.

Reference Details: The documentation explicitly states this cmdlet "can be used to update the license assignment for a user" and details the -AddLicenses and -RemoveLicenses parameters

which are central to the solution.

2. Microsoft Learn. (2023

September 15). What is group-based licensing in Azure Active Directory? Microsoft Entra Documentation.

Reference Details: Under the section "A user has a license that conflicts with a group license

" the documentation explains that a user can have both a directly assigned license and a group-inherited license. This confirms that assigning the E5 group license does not automatically remove the direct E3 license

necessitating a separate removal action.

3. Microsoft Learn. (n.d.). Update-MgGroup. Microsoft Graph PowerShell Documentation. Retrieved from https://learn.microsoft.com/en-us/powershell/module/microsoft.graph.groups/update-mggroup.

Reference Details: The documentation shows that this cmdlet is used to "Update the properties of a group object." This confirms its scope is limited to the group itself

not the direct license assignments of its members.

The combined security information registration process prompts users to register authentication methods for both Azure AD Multi-Factor Authentication (MFA) and Self-Service Password Reset (SSPR). Since MFA is enforced, the new user, User1, must register at least one method that satisfies the MFA policy during their first sign-in.

The Microsoft Authenticator app and FIDO2 security keys are both strong authentication methods that can be used for MFA and are available for users to self-register during the initial combined registration experience. These methods allow the user to complete the mandatory setup and secure their account from the outset.

B. a hardware token: Hardware OATH tokens must be registered by an administrator for the user; they cannot be self-registered by the user during the initial sign-in process.

C. a one-time passcode email: Email is a method available for SSPR only, not for MFA. It cannot be used to satisfy the initial MFA registration requirement that triggers the combined registration process.

D. Windows Hello for Business: This is provisioned on a specific device after a user has already successfully authenticated with MFA. It is not an option available during the initial registration flow itself.

1. Microsoft Learn. (2023). Combined security information registration for Azure Active Directory overview. In "Authentication methods". This document lists the available methods for combined registration

including "Microsoft Authenticator app" and "FIDO2 security key". It also specifies that "Email address" and "Security questions" are available for SSPR only.

2. Microsoft Learn. (2023). Authentication methods and features. In "Authentication". This table confirms that FIDO2 Security Key and Microsoft Authenticator are valid for both MFA and SSPR

while Email is only for SSPR.

3. Microsoft Learn. (2023). Passwordless security key sign-in to Windows 10 devices with Azure Active Directory. In "Enable passwordless security key sign-in". The section "User registration and management of FIDO2 security keys" describes the self-service registration process at https://myprofile.microsoft.com.

4. Microsoft Learn. (2023). How to register and manage OATH hardware tokens in Azure AD. In "OATH tokens". The "Prerequisites" section states

"Admins need to register the hardware tokens for each user." This confirms it is not a self-service method for a new user.

When registering a web application in Azure AD to enable authentication, the Redirect URI (also known as a reply URL) is a critical security configuration. After a user successfully authenticates with the Microsoft identity platform, Azure AD redirects the user's browser back to this specific URI. The redirection includes the security token (an ID token or access token) required by the application to complete the sign-in process and verify the user's identity. Without a correctly configured Redirect URI, the authentication flow cannot be completed, and the application will not receive the necessary token.

A. The executable name is not a standard configuration property for a web app registration in Azure AD; it is more relevant for identifying native desktop applications.

B. The bundle ID is a unique identifier required when registering native applications for Apple's iOS or macOS platforms, not for a .NET web app.

C. The package name is a unique identifier required when registering native applications for the Android platform, not for a .NET web app.

---

1. Microsoft identity platform documentation

"Quickstart: Register an application with the Microsoft identity platform."

Reference: Under the section "Register an application

" step 5

"Add a redirect URI

" it states: "Select the platform for your application - Web... Enter the redirect URI for your application." This explicitly shows that for a web app

the redirect URI is a required configuration.

Source: https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-register-app#register-an-application

2. Microsoft identity platform documentation

"Redirect URI (reply URL) restrictions and limitations."

Reference: The document's overview section states

"A redirect URI

or reply URL

is the location where the Microsoft identity platform redirects a user's client and sends security tokens after authentication. For example

in a web application

the redirect URI is the location where the user is sent after they sign in."

Source: https://docs.microsoft.com/en-us/azure/active-directory/develop/reply-url

3. Microsoft Learn

SC-300 Courseware

"Register an application."

Reference: In the learning module for implementing application access

the section on app registration details the required settings. It specifies: "When you register a web app

you must add a redirect URI. The redirect URI is the URI where users are sent after they've been authenticated." It also shows that Package Name and Bundle ID are for mobile platforms.

Source: https://learn.microsoft.com/en-us/training/modules/implement-manage-app-permissions/2-register-app

The Microsoft Entra ID sign-in logs are the most direct and efficient tool for diagnosing user access issues. These logs capture detailed information about every interactive user sign-in attempt, including the user, the target application (Microsoft Defender for Cloud Apps), the status (success or failure), and the specific reason for any failure. An administrator can quickly filter the logs for User1's attempts to access the portal and identify the root cause, such as a Conditional Access policy block, an incorrect password, or a failed MFA prompt. This approach directly addresses the problem with the least administrative overhead.

A. Log Analytics: This is a more complex tool requiring data to be forwarded and queries to be written, which is not the most minimal administrative effort.

C. audit logs: These logs track administrative actions and configuration changes within the tenant, not user sign-in attempts.

D. provisioning logs: These logs track the automated creation, update, and deletion of user identities in applications, not interactive sign-in events.

1. Microsoft Learn. "Sign-in logs in Microsoft Entra ID." Microsoft Entra documentation. Accessed October 10

2023. In the "What can you do with it?" section

it explicitly states a key use case is to "Troubleshoot sign-in issues for a user." The documentation further details that the logs contain the "Sign-in error code" and "Failure reason" which are essential for diagnosing the problem.

2. Microsoft Learn. "Troubleshoot sign-in problems with Conditional Access." Microsoft Entra documentation. Accessed October 10

2023. This document demonstrates using the sign-in logs as the primary tool for troubleshooting access failures

stating

"The first place to look for more information is the Microsoft Entra sign-in logs... The sign-in log for the user should tell you why a user is or is not getting a prompt for MFA or why a policy is or is not applying."

3. Microsoft Learn. "Reporting and monitoring overview." Microsoft Entra documentation. Accessed October 10

2023. This overview clearly distinguishes the different log types. It describes sign-in logs for "information about the usage of managed applications and user sign-in activities

" while audit logs are for "system activity for users and groups

" and provisioning logs are for "system activity for applications." This confirms that sign-in logs are the correct choice for the described scenario.

In an access review whose reviewer type is set to “Managers of users,” Azure AD sends each review request to the user listed in the Manager attribute of every targeted account. If all IT-administrator objects currently list Megan Bowen as their Manager, every review is routed to her. Updating each administrator’s user object so that its Manager property reflects the correct departmental manager will cause Azure AD to deliver the review to the appropriate person; no other configuration change is required. Why Incorrect Option is Wrong: B. No – Changing the Manager attribute on the targeted user objects directly affects who receives manager-based access reviews, so the goal is achieved.

1. Microsoft, “Create an access review of group membership in Microsoft Entra ID,” Docs, Reviewer options – Managers of users, para. 2 (2024-05-05).

2. Microsoft, “User profile attributes – Manager,” Microsoft Entra documentation, Section “How the manager attribute is used” (2024-02-12).

Microsoft Defender for Cloud Apps automatically discovers cloud application usage (Shadow IT) by analyzing traffic logs from sources like Microsoft Defender for Endpoint. This discovery process populates the "Discovered apps" page. To efficiently identify users accessing a specific application like Facebook, the first administrative action is to classify the app. By tagging Facebook as "Unsanctioned," you are not blocking it, but rather categorizing it for easier monitoring and filtering. This simple, low-effort action allows you to use the Cloud Discovery filters to immediately isolate all usage data for Facebook and identify the specific users, devices, and browsers involved.

B. Create an app configuration policy in Microsoft Endpoint Manager.

This is incorrect because app configuration policies are used to configure settings for managed applications on enrolled devices, not for discovering or identifying unmanaged cloud app usage.

C. Create a Defender for Cloud Apps access policy.

This is a subsequent step. Access policies are control mechanisms to manage real-time sessions (e.g., block downloads) after an app has already been discovered and classified.

D. Create a Conditional Access policy.

This is also a control mechanism. Conditional Access policies enforce access requirements (like MFA) for apps but are not the primary tool for the initial discovery and identification of users.

---

1. Microsoft Learn. (2023). Sanctioning/unsanctioning an app. In Microsoft Defender for Cloud Apps documentation. Retrieved from https://learn.microsoft.com/en-us/defender-cloud-apps/governance-actions#sanctioningunsanctioning-an-app.

Section: Sanctioning/unsanctioning an app.

Quote: "Marking an app as unsanctioned doesn't block use

but enables you to more easily monitor its use with the Cloud Discovery filters." This directly supports that unsanctioning is a primary step for monitoring and identification.

2. Microsoft Learn. (2023). Working with discovered apps. In Microsoft Defender for Cloud Apps documentation. Retrieved from https://learn.microsoft.com/en-us/defender-cloud-apps/discovered-apps.

Section: Discovered apps page.

Content: This document explains that after apps are discovered

a primary task for the administrator is to review and classify them. It states

"Once you've identified an app

you can sanction or unsanction it." This establishes sanctioning/unsanctioning as a foundational administrative step in managing discovered apps.

3. Microsoft Learn. (2023). Set up Cloud Discovery. In Microsoft Defender for Cloud Apps documentation. Retrieved from https://learn.microsoft.com/en-us/defender-cloud-apps/set-up-cloud-discovery.

Section: Cloud Discovery dashboard.

Content: This document describes the workflow for Shadow IT discovery. The process begins with data collection and analysis

which is largely automatic. The first manual administrative phase involves evaluating the discovered apps

which includes the act of sanctioning or unsanctioning to apply organizational policy and facilitate further monitoring.