SC-500 Practice Questions

Based on the "Privileged Identity Management Configuration" table provided in the case study, the specific policy configured for the "AI Administrator" role strictly designates "Admin1 and Admin3 only" as the eligible approvers. Furthermore, the table explicitly defines the "Maximum Active Duration" for this role as "1 day". When User1 requests activation for this role, Entra Privileged Identity Management (PIM) enforces these pre-configured limits.

Microsoft Learn: "Configure Microsoft Entra role settings in Privileged Identity Management" - Section: Activation maximum duration & Require approval. (https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-how-to-change-default-settings)

To automatically install a custom security extension on a newly deployed virtual machine and remediate existing non-compliant ones, the policy must use the DeployIfNotExists effect. This effect executes a template deployment when the evaluated resource (the VM) lacks the specified related resource (the extension).

For the policy to execute this deployment during evaluation or a remediation task, it requires an identity with adequate permissions to modify the resource. Azure Policy remediation specifically uses managed identities (not service principals) to securely authenticate and apply these changes. Assigning the managed identity the Contributor role grants the necessary permissions to install the VM extension without violating the principle of least privilege by assigning the Owner role.

Microsoft Learn: Understand Azure Policy effects – Details the usage of the DeployIfNotExists effect for deploying resources when they evaluate as non-compliant. (https://learn.microsoft.com/en-us/azure/governance/policy/concepts/effects)

Microsoft Learn: Remediate non-compliant resources with Azure Policy – Specifies that remediation tasks require a managed identity (system-assigned or user-assigned) and that the identity must be granted the appropriate role-based access control (RBAC) permissions, such as Contributor, to deploy the missing resources. (https://learn.microsoft.com/en-us/azure/governance/policy/how-to/remediate-resources)

To achieve the scenario requirements, two distinct configurations are necessary across the platforms:

1. Microsoft Defender XDR: You must enable the Microsoft 365 app connector. Real-time protection evaluates and blocks suspicious tool invocations autonomously, but according to Microsoft documentation, if the Microsoft 365 connector is not active, the related alerts and incidents will not surface in the Microsoft Defender portal.
2. Power Platform: You must configure the Microsoft Entra application ID for agent integration. This App ID acts as the authenticated bridge allowing the Copilot Studio agent to share runtime telemetry and tool invocation requests with the external threat detection provider (Defender XDR) before executing actions. While configuring the error behavior to "Block the query" is an option in Power Platform, this setting only applies to system timeouts or errors, whereas actual malicious blocks are handled natively once the Entra application ID integration is established.

Microsoft Learn: Enable security for AI agents using Microsoft Defender. (Section: Connect data sources -> Connect Microsoft 365). Documentation explicitly states: "For Copilot Studio agents, if the Microsoft 365 connector isn't connected, real-time protection continues to block suspicious activity during runtime, but alerts and incidents related to these actions don't appear in the Microsoft Defender portal."

Microsoft Learn: Enable external threat detection and protection for Copilot Studio custom agents (preview). (Section: Configure threat detection in Power Platform admin center). Documentation specifies that administrators must "Select Allow Copilot Studio to share data with a threat detection provider" and input the Azure Entra App ID to enable the system to evaluate and block tool invocations.

Microsoft Learn: Protect AI agents in real time using Microsoft Defender. (Section: How real-time protection works). Details how Defender integrates with Copilot Studio to inspect activity throughout the agentic loop and block risky actions before they execute.

To adhere to the principle of least privilege, AKS1 requires only the ability to pull container images from the Azure Container Registry (ACR). The AcrPull built-in role provides exactly this specific permission without granting management or push rights. For the deployment automation managed identity (ID1) to successfully modify and deploy Azure resources across the environment, the Contributor role is required. Contributor grants the necessary rights to create and manage resources while restricting the ability to assign access rights to others (which would require the overly permissive Owner role).

Microsoft Learn, "Authenticate with Azure Container Registry from Azure Kubernetes Service (AKS)," Azure Kubernetes Service (AKS) Documentation. Specifies that granting the AcrPull role to the AKS managed identity is the standard and least-privilege method for ACR integration.

Microsoft Learn, "Azure built-in roles," Azure Role-Based Access Control (RBAC) Documentation. Defines the Contributor role as granting full access to manage all resources while explicitly denying the ability to assign roles in Azure RBAC, satisfying the deployment automation requirement under least privilege constraints.

The objective is to prevent Security Copilot contributors from managing organization-wide plugins while allowing them to manage plugins for their own sessions. Microsoft Security Copilot uses role-based access control at two distinct scopes for custom plugin management: tenant scope (organization-wide) and user scope (for their own sessions).

To achieve the desired outcome, you must configure the tenant scope setting to permit only users with the 'Owner' role to manage these shared plugins. Selecting "Owners only at the tenant scope" directly enforces this restriction at the organizational level, thereby preventing contributors from managing these plugins. This change does not affect the user scope settings, so contributors retain their ability to create and manage plugins for personal use.

A. Contributors and Owners at the tenant scope: This is the permissive default setting that allows contributors to manage organization-wide plugins, which is what needs to be changed.

B. Owners only at the user scope: This incorrectly restricts contributors from creating plugins for their own sessions, which violates a specific requirement of the solution.

C. Contributors and Owners at the user scope: This setting correctly allows contributors to manage their own plugins but fails to address the primary requirement of restricting their access to organization-wide plugins.

1. Microsoft Learn

"Manage plugins in Microsoft Security Copilot": This document details the plugin management settings. Under the section "Manage who can create custom plugins

" it explicitly states the two scopes:

User scope: "These plugins are only available to the user who created them."

Tenant scope: "These plugins are available to all users in the organization."

It further explains the permission options for each scope: "Owners only" or "Contributors and Owners." To restrict tenant-level management

the "Tenant scope" must be set to "Owners only."

Source: Microsoft. (n.d.). Manage plugins in Microsoft Security Copilot. Microsoft Learn. Retrieved from https://learn.microsoft.com/en-us/security-copilot/manage-plugins#manage-who-can-create-custom-plugins

2. Microsoft Learn

"Roles and authentication in Microsoft Security Copilot": This document defines the capabilities of the Owner and Contributor roles. It clarifies that Owners have full permissions

including managing all settings

while Contributors have more limited access. Restricting tenant-level plugin management to Owners aligns with this principle of least privilege.

Source: Microsoft. (n.d.). Roles and authentication in Microsoft Security Copilot. Microsoft Learn. Retrieved from https://learn.microsoft.com/en-us/security-copilot/roles-authentication#security-copilot-roles

To create a trusted image in an Azure Container Registry (ACR) with content trust enabled, a user must perform two distinct actions: pushing the image to the registry and then signing it. The principle of least privilege dictates assigning roles that grant only the necessary permissions for these specific actions.

The AcrPush role grants the Microsoft.ContainerRegistry/registries/push/write permission, which is required to upload an image to the registry. The AcrImageSigner role grants the Microsoft.ContainerRegistry/registries/sign/write permission, which is specifically required to sign images for content trust. Assigning both roles provides User1 with the exact permissions needed without granting excessive privileges.

A. AcrQuarantineWriter: This role is for pushing images to a quarantine repository, a separate feature from content trust, and does not grant signing permissions.

B. Contributor: This is a management-plane role that grants broad permissions to manage the ACR instance itself, violating the principle of least privilege. It does not inherently include data-plane permissions for signing.

C. AcrQuarantineReader: This role only allows pulling images from a quarantine repository and is irrelevant to creating or signing new images.

1. Microsoft Learn

Content trust in Azure Container Registry. This document explicitly states the required roles. In the "Push a trusted image" section

it says

"To push a trusted image tag to your container registry

you must have permissions to both push the image and sign images. In addition to the AcrPush role (or equivalent) to push images

you need to assign the AcrImageSigner role to the user."

Source: https://learn.microsoft.com/en-us/azure/container-registry/container-registry-content-trust#push-a-trusted-image

2. Microsoft Learn

Azure Container Registry roles and permissions. This page details the specific permissions for each built-in role.

AcrPush: "push an image

or push another supported artifact such as a Helm chart

to the registry." Includes action: Microsoft.ContainerRegistry/registries/push/write.

AcrImageSigner: "sign images

typically assigned to an automated process that uses a service principal." Includes action: Microsoft.ContainerRegistry/registries/sign/write.

Source: https://learn.microsoft.com/en-us/azure/container-registry/container-registry-roles?tabs=azure-cli#roles

To enable Microsoft Defender for Endpoint (MDE) capabilities, specifically Endpoint Detection and Response (EDR), on servers that already have a third-party antivirus (AV) solution, Microsoft Defender Antivirus must be configured to run in passive mode. This configuration prevents conflicts that arise from running two active antimalware solutions simultaneously. In passive mode, Defender Antivirus does not perform real-time scanning or threat remediation, deferring to the active third-party AV. However, its engine remains available for the MDE EDR sensor to use for detection and reporting. The ForceDefenderPassiveMode registry value is the explicit method to ensure Defender Antivirus enters this state, thereby meeting both requirements.

A. Set the Microsoft Defender for Endpoint service to Disabled.

This would disable the EDR sensor (MsSense.exe), which directly contradicts the requirement to enable EDR capabilities.

B. Disable Microsoft Defender Antivirus real-time protection by using Set-MpPreference.

While this disables a conflicting feature, forcing passive mode is the officially recommended and more robust method for ensuring full coexistence and EDR functionality.

D. Enable EDR in block mode.

EDR in block mode is a feature that enhances EDR, but it requires Microsoft Defender Antivirus to be in passive mode as a prerequisite. It is a subsequent step, not the initial configuration to prevent conflicts.

---

1. Microsoft Learn. (2024). Microsoft Defender Antivirus compatibility with other security products.

Section: "How passive mode works" and "How to set passive mode"

Content: This document explicitly states

"To set passive mode

you can use one of several methods

such as... a registry key." It then specifies the registry key: Path: HKLM\SOFTWARE\Policies\Microsoft\Windows Advanced Threat Protection

Name: ForceDefenderPassiveMode

Type: DWORD

Value: 1. This directly validates option C as the correct method to ensure coexistence.

2. Microsoft Learn. (2024). Onboard Windows Server to the Microsoft Defender for Endpoint service.

Section: "Microsoft Defender Antivirus and your non-Microsoft antivirus solution"

Content: "If you are using a non-Microsoft antimalware solution on your Windows Servers

you can run Microsoft Defender Antivirus in passive mode... You can set passive mode by using the following registry key: Path: HKLM\SOFTWARE\Policies\Microsoft\Windows Advanced Threat Protection

Name: ForceDefenderPassiveMode..." This confirms the procedure for the exact server types mentioned in the question.

3. Microsoft Learn. (2024). Endpoint detection and response in block mode.

Section: "Prerequisites for EDR in block mode"

Content: The documentation lists as a prerequisite: "Microsoft Defender Antivirus is in passive mode." This confirms that enabling EDR in block mode (Option D) is a secondary action that depends on passive mode (Option C) being configured first.

To securely expose specific virtual machines (VM1 and VM2) to a partner network (VNet2) residing in a different Microsoft Entra tenant without exposing the entire virtual network, Azure Private Link is the required architecture. You must configure an Azure Private Link service in VNet1, which utilizes an Azure Standard Load Balancer to route incoming traffic directly to the target VMs. In VNet2, you configure a private endpoint that establishes a secure connection to the Private Link service. This satisfies the requirement to deny access to other Sub1 resources by strictly isolating the connection to the approved service, whereas VNet peering would broadly route traffic between the entire networks by default.

Microsoft Corporation. "What is Azure Private Link?" Azure Virtual Network Documentation. Section: Key Benefits (Cross-tenant access and Data leakage protection). Available at: https://learn.microsoft.com/en-us/azure/private-link/private-link-overview

Microsoft Corporation. "Create an Azure Private Link service." Azure Virtual Network Documentation. Section: Prerequisites (Standard Load Balancer requirement for exposing IaaS resources). Available at: https://learn.microsoft.com/en-us/azure/private-link/create-private-link-service-portal

Agent 1 operates interactively to summarize a specific user's email. This requires delegated permissions, which are used when an application or agent calls Microsoft Graph on behalf of a signed-in user. These permissions ensure the agent can only access the data the user themselves is authorized to access.

Agent 2 operates autonomously as a background process to send nightly updates. This scenario requires application permissions (also known as app roles), which are explicitly designed for daemon applications or background services that run with their own identity and without a signed-in user present.

Source 1: Microsoft Learn, Overview of Microsoft Graph permissions, "Permission types". Document identifier: [https://learn.microsoft.com/en-us/graph/permissions-overview](https://learn.microsoft.com/en-us/graph/permissions-overview). (Details the explicit differences between delegated access for signed-in users and app-only access for background services).

Azure Bastion requires specific Network Security Group (NSG) configurations on the AzureBastionSubnet to route traffic properly. For inbound connections, users access the Azure Bastion host externally through the Azure portal using an HTML5 web client. This session is secured via TLS, which mandates that TCP port 443 (HTTPS) is allowed inbound from the internet.

For egress traffic, the Azure Bastion host brokers the session directly to the target virtual machines in the peered or local subnets. Because the scenario explicitly requires deploying Bastion to provide secure RDP (Remote Desktop Protocol) access to the virtual machines on Subnet1, you must allow outbound traffic from the Bastion subnet to Subnet1 over TCP port 3389, the standard port for RDP.

Microsoft Learn: "Working with NSG access and Azure Bastion"

Document ID: Azure/bastion/bastion-nsg

Section: "Ingress traffic: Ingress Traffic from public internet" (specifies allowing TCP port 443).

Section: "Egress traffic: Egress Traffic to target VMs" (specifies allowing TCP ports 3389 and 22 for RDP and SSH, respectively).