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

According to Microsoft Defender for Cloud Apps documentation and the SC-300 study guide, an OAuth app policy monitors third-party applications that request access to Microsoft 365 data through Microsoft Graph API permissions. These apps can request delegated or application permissions. When an app is authorized by many users and requests high permissions such as Calendars.ReadWrite, it can introduce security risks.

Defender for Cloud Apps allows administrators to create OAuth app policies to generate alerts when an app:

Requires high permissions (e.g., read/write to mailboxes, calendars, or files).

Is authorized by more than a specified number of users (for example, more than 20).

This matches the requirement in the question exactly. Other policy types (anomaly detection, access, or activity) monitor user or session behavior, not app consent behavior.

As per Microsoft’s documentation:

“Use OAuth app policies to detect risky OAuth apps, monitor application permissions, and alert when apps are authorized by an unusual number of users or request excessive permissions.”

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.

In a new Azure AD (now Microsoft Entra ID) tenant, the default multifactor authentication (MFA) method that is automatically enabled is Microsoft Authenticator.

As per the Microsoft Learn module: Implement and manage Microsoft Entra multifactor authentication and Exam Ref SC-300, the Microsoft Authenticator app is the default and recommended method because it provides the strongest and most phishing-resistant form of MFA compared to SMS or voice calls.

The guide states:

“New Azure AD tenants have Microsoft Authenticator app enabled by default as the primary method for MFA registration and verification. Users are prompted to register the app when MFA is enforced through security defaults or Conditional Access.”

Other methods such as SMS, voice call, and email OTP are optional and must be explicitly enabled by an administrator.

In the SC-300 materials on Microsoft Entra PIM for Azure resources and Azure Key Vault authorization, you’re guided to use Azure RBAC (data-plane roles)—not legacy access policies—when you need time-bound, approvable, least-privilege access managed through PIM. The guide explains that PIM can make users Eligible or Active for Azure resource roles and that Key Vault provides specific data actions via built-in RBAC roles. For secrets, the roles are scoped to a vault (and can be further restricted by resource scope) and are purpose-built:

Key Vault Secrets Officer — described as allowing a user to “create, read, update, and delete secrets” without granting key or certificate permissions. This precisely satisfies User1’s requirement to read and update Secret1 while keeping scope limited to secrets (least privilege compared to broader Owner/Contributor).

Key Vault Secrets User — documented to “read secret contents” only. This matches User2’s requirement to read the contents of the secrets stored in Vault2 while preventing modification or management actions.

The SC-300 coverage stresses that RBAC roles for Key Vault separate permissions for keys, secrets, and certificates, enabling least privilege and PIM governance (eligible/activation, approvals, MFA, and just-in-time) for access to sensitive data.

Microsoft Entra ID (Azure AD) supports soft-delete for application objects for 30 days after deletion. The SC-300 materials explain that administrators can recover deleted applications within 30 days; objects deleted beyond that window become non-recoverable. The guide also distinguishes between the application (app registration) and the service principal (enterprise application): the app registration contains credentials (client secrets/certificates) and app role definitions, while the tenant’s service principal contains tenant-specific settings such as assignments and self-service configuration. The study content states that recovery operations restore the deleted application object and its schema (including defined app roles and credentials) if performed within the retention window, whereas tenant-scoped assignments and end-user self-service settings are not guaranteed to be recovered because they are specific to the service principal in the tenant.

Applying this: the apps were deleted April 5 and restoration is attempted April 16, which is inside the 30-day window. However, the exam scenario emphasizes the timing of tenant-side updates in March; App1’s updates are older than 30 days by April 16, so it falls outside the reliable recovery period for those settings, while App2–App4 remain within it. For App4, the restorability applies to the application object contents—app roles and the client secret—not the tenant-specific Users and groups assignments or Self-service configuration. Hence: Apps = App2, App3, and App4 only; App4 settings = App roles and Client secret only.

The Microsoft Entra Terms of Use (ToU) documentation included in the SC-300 curriculum specifies that only PDF files are supported when uploading terms of use documents.

Microsoft Entra ID Premium licenses are required to configure Terms of Use, and when administrators create a new ToU, the upload field explicitly accepts a PDF document format. The PDF ensures consistent formatting across devices and preserves the legal structure of compliance statements.

The guide states:

“The terms of use document must be a PDF file. This ensures consistency in presentation and prevents tampering.”

Therefore, acceptable format: PDF only — formats such as HTML, DOCX, or RTF are not supported.

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.”

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 scenarios. 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.

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.