Microsoft Azure Security Engineer Associate Practice Test (AZ-500)

Finance.Read must be a delegated permission so it is presented only when a user is involved in the authorization flow; application permissions are intended for daemon or service scenarios without user context. Setting Who can consent to Administrators only ensures that only tenant admins can approve the permission for users or service principals, preventing end users from self-consenting. Choosing Application would make the permission available to daemon apps, contradicting the requirement, and allowing Users consent would let non-admin users approve the permission, which is also disallowed.

Azure Container Instances exposes the ContainerInstanceConsoleLogs and ContainerInstanceEvents diagnostic categories. A diagnostic setting that targets a Log Analytics workspace streams those records, making them queriable with Kusto and suitable for alert rules. A built-in Azure Policy can deploy the required diagnostic setting at scale, ensuring that new and existing container groups are configured automatically. Azure Monitor for containers is limited to Kubernetes clusters, installing the Azure Monitor agent inside every container is unsupported for ACI, and enabling Microsoft Defender for Containers does not configure log collection for ACI diagnostic categories.

To use the VPN gateway that exists in a peered virtual network, you configure gateway transit. On the virtual network that owns the gateway (VNet1), you enable Allow gateway transit. On the peered virtual network that needs to route through that gateway (VNet2), you must enable Use remote gateways. The other options-Allow virtual network access, Allow forwarded traffic, and Allow gateway transit-either provide basic connectivity or are applied to the hub network, not the spoke that consumes the gateway.

Using Enterprise applications is recommended when you need to grant tenant-wide consent to an already-provisioned service principal. Selecting Grant admin consent approves the listed delegated and application permissions on behalf of every user and service in the directory. After the grant is completed, users are no longer prompted and the app receives the access token containing only the approved scope. Editing requiredResourceAccess in the app registration does not create the pre-authorization; it still requires an admin to grant consent later. Enabling the admin consent workflow simply inserts an approval process for individual users, so a prompt would still appear. Azure RBAC app-role assignments control who can sign in to the application but do not satisfy OAuth consent. Therefore, granting admin consent in Enterprise applications is the correct action.

The built-in cloud app named Microsoft Azure Management represents Azure Resource Manager, the Azure portal, Azure PowerShell, Azure CLI, and other management endpoints. Targeting this single cloud app lets you enforce MFA for management plane access only, without affecting sign-ins to Microsoft 365 workloads. Selecting All cloud apps would also cover Microsoft 365. The Office 365 app scope would not include Azure management endpoints, and there is no built-in cloud app called Azure Resource Manager API that applies broadly to the portal, PowerShell, and CLI.

When you define or edit a delegated permission scope for a custom API under Expose an API, select the option Admin consent required. This sets the scope's type property to "Admin" (Who can consent: Admins only). Once configured, regular users can no longer grant the permission; a tenant administrator with the appropriate role must provide consent on behalf of the organization. Settings such as User assignment required, single-tenant versus multitenant configuration, or managed identity assignments do not influence whether users can self-consent to API permissions.

Granting the UNMASK permission on the dbo.Employees table lets the Analytics role bypass masking only for that specific table, exposing the true Salary values while conferring no data-modification or schema-alteration rights. Granting UNMASK at the database scope would reveal unmasked data in every masked column across the database, which is broader than required. ALTER ANY MASK would allow users to create, alter, or drop masking rules, and CONTROL on the table would provide full DDL and DML access-both exceed least-privilege.

The action Microsoft.Insights/diagnosticSettings/read grants read-only access to existing diagnostic settings, letting users see which logs and metrics are collected and where they are sent. It does not permit creating, updating, or deleting diagnostic settings.

The write and delete variants would allow modifications, violating the requirement. Microsoft.Resources/deployments/read is unrelated to diagnostic settings and therefore does not satisfy the requirement.

Enabling Azure SQL auditing at the server level automatically applies to every existing database on the logical server and to any database created in the future, so no additional configuration is needed. Auditing the master database alone does not cascade to user databases. Configuring Azure Monitor diagnostic settings or deploying SQL Server Audit objects per database would have to be repeated each time a new database is created, increasing administrative overhead. Therefore, server-level auditing is the correct and most efficient choice.

A user-assigned managed identity is created as an independent Azure resource. Because its lifecycle is not tied to any single workload, the identity continues to exist if the scale set or the web app is deleted or redeployed. The same user-assigned identity can be attached to multiple Azure resources, allowing you to grant Key Vault access once and reuse the assignment. A system-assigned identity cannot be shared and is removed with its parent resource, and using separate identities or client secrets would increase the number of role assignments and management overhead.

Azure AD-based authentication for point-to-site VPN connections in Azure is only supported when the OpenVPN tunneling protocol is enabled on a route-based VPN gateway that uses a VpnGw1 or higher SKU. OpenVPN supports Azure AD tokens and allows Conditional Access policies such as MFA. SSTP is not compatible with Azure AD authentication, and certificate (EAP-TLS) or RADIUS methods do not satisfy the requirement of Azure AD-based MFA without additional infrastructure. A policy-based gateway cannot be used for OpenVPN or Azure AD authentication.

Enabling HTTPS on the front-end endpoint provides TLS encryption between clients and Azure Front Door. Setting the origin protocol policy of the App Service origin to HTTPS only forces Front Door to use TLS when it forwards requests to the backend, preventing any fallback to HTTP. A WAF policy can block or allow requests but does not control the protocol used between Front Door and its origin. Configuring HTTP-to-HTTPS redirection in App Service protects only direct traffic to the site and does not stop Front Door from using HTTP. Using Private Link changes the network path but still allows either HTTP or HTTPS, so it does not by itself guarantee encryption on the second hop.

Automatic certificate rotation from Azure Key Vault is supported only by Application Gateway instances that run on the v2 SKU. Integrating Key Vault requires the gateway to have a managed identity that is granted secret-level access to the vault. A v1 gateway cannot be linked directly to Key Vault, so the initial step is to migrate or redeploy the gateway to the v2 SKU and assign it a managed identity. Importing the certificate into Key Vault, configuring runbooks, or trying to enable rotation on a v1 gateway will not satisfy the requirement because v1 does not support native Key Vault integration.

Create a shared access signature (SAS) that is signed with a user-delegation key. The user-delegation key is obtained through Microsoft Entra ID authentication by whoever creates the SAS, so the storage account access key never leaves Azure. If the SAS is later compromised or no longer needed, you can immediately invalidate it by calling the Revoke User Delegation Keys operation (or the corresponding CLI/PowerShell command), which cancels all user-delegation keys issued before the revocation time. A service SAS relies on the account key, public anonymous access removes all authentication, and distributing the account key grants full account permissions and is hard to revoke granularly.

ACR tokens let you create repository-scoped, non-Azure-AD credentials. By first defining a scope map that grants only the content/read (pull) action on the dev repository and then creating a token linked to that scope map, you obtain a username/password pair that is limited to that repository. The credentials can be regenerated or revoked at any time, providing the desired short-lived access. Assigning the AcrPull role at registry scope or enabling the admin user would grant access to every repository. Anonymous pull cannot be restricted to a single repository and does not meet the security goal.

Agentless scanning for Azure virtual machines is provided only with Microsoft Defender for Servers Plan 2. After upgrading the subscription to Plan 2, you enable the Agentless scanning for machines setting under Environment settings in Microsoft Defender for Cloud. Vulnerability assessment and malware detection are then performed from storage-based snapshots, so no Qualys, Log Analytics, or Microsoft Defender agents are required or deployed. The other options continue to rely on agents (Qualys extension, Microsoft Defender Vulnerability Management via the MDE sensor, or the Log Analytics agent) and therefore do not meet the requirement.

Background services that call an API without a signed-in user need an application permission usable with the client-credentials flow. In an app registration, such a permission is created by defining an application role whose Allowed member type is set to Application. Application permissions always require admin consent, ensuring administrators in external tenants must approve access before tokens can be issued. Delegated scopes, public-client settings, or single-tenant configurations would not meet the stated requirements.

The most restrictive option is to grant access only to the subnet that hosts the function app. First, enable the Microsoft.KeyVault virtual network service endpoint on AppSubnet, then add that subnet to the Key Vault's virtual network rules. Traffic from resources in the subnet is routed to the vault over the Azure backbone, and all other sources, including other Microsoft services, remain blocked.

Allowing trusted Microsoft services would open access for many Azure platforms you do not use. Relying on the function app's outbound IP addresses is fragile because those addresses can change and does not prevent other services using the same public IP range. Enabling public network access defeats the requirement to block other Azure services, even if a managed identity is used.

The on-premises DNS servers must resolve the storage account's FQDN to the private IP that Azure assigned to the private endpoint. The recommended approach is to create a conditional forwarder that sends all queries for the privatelink.blob.core.windows.net zone to a DNS forwarder (for example, Azure DNS Private Resolver or a custom DNS server) located inside VNET1, where the private DNS zone is linked. This causes on-premises queries for contososa.blob.core.windows.net to be answered with the private IP.

Adding a static A record on-premises is not advised because the private IP can change if the endpoint is recreated. Disabling public network access does not fix DNS resolution; the name would still resolve to the public IP and connectivity would fail. Service endpoints are unrelated to private endpoints and do not influence DNS behavior.

The Modify effect can change or set resource properties during create or update operations and can also be used by remediation tasks to update existing resources. If the required change cannot be applied, the request is denied. Audit only records non-compliance, Deny blocks every non-compliant request without remediation, and Append adds properties only during creation or update but cannot remediate existing resources. Therefore, Modify is the only effect that meets all the requirements.