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

Configuring a key rotation policy on AppKey with a lifetime action of Rotate instructs Azure Key Vault to create a new version of the key every 30 days. The key name and base URI remain unchanged, so applications that call the base identifier automatically begin using the newest version without modification. Setting only an expiration date makes the key unusable after 30 days but does not create a new version. Soft delete or purge protection protect against accidental deletion rather than perform rotation. While an Azure Automation runbook could call the rotate command on a schedule, it requires additional resources and ongoing maintenance, making it a less efficient solution for this requirement.

Azure Bastion connects to the target VM over its private network using the standard management port (TCP 3389 for Windows). The traffic originates from an address inside the same virtual network, which is represented in NSG and JIT rules by the VirtualNetwork service tag. Therefore, the JIT rule should open TCP port 3389 only for the VirtualNetwork tag. Allowing the Internet tag would expose the port publicly, opening port 443 would not let Bastion reach the VM, and opening port 22 targets SSH rather than RDP.

The microsoft.directory/users/password/update permission allows a principal to perform password resets for any user but does not grant rights to delete users or update other user properties. Therefore, including only this permission in the custom Microsoft Entra role lets Helpdesk staff reset passwords while preventing broader user management capabilities. The other listed permissions either allow additional user changes, such as creating or deleting users, or are unrelated to user password management.

A Private Endpoint assigns a private IP address from the connected virtual network to the Azure SQL Database. Traffic to the database remains on the virtual network and can traverse VPN or ExpressRoute private peering without ever using the public endpoint. Linking a private DNS zone allows clients to resolve the database's fully qualified domain name to the private IP automatically.

Service endpoints do not work from on-premises networks because traffic still targets the public endpoint. IP firewall rules still expose the database's public endpoint to the internet. Azure Front Door is a public reverse-proxy service and does not satisfy the private-IP-only requirement.

Azure Front Door Standard or Premium can host both origins under one global endpoint. You create two routes: one matching /images/* that forwards to the Storage static website with caching enabled, and another matching /app/* that forwards to the App Service with caching disabled. A Front Door WAF policy attaches to the profile, giving edge inspection. Because all capabilities-global routing, CDN-grade caching, and WAF-reside in one Front Door deployment, no additional services are required. Other options either need extra components or lack required features.

Agentless vulnerability assessment in Microsoft Defender for Servers Plan 2 works by creating secure snapshots of the disks that back a VM. The capability is supported only for VMs that use Azure managed disks, because snapshots can be taken only from managed disks. VMs that rely on unmanaged disks or that have ephemeral OS disks are skipped automatically. Consequently, a VM must be configured with managed disks for agentless vulnerability assessment to run.

Azure Front Door provides a global point of presence that performs layer-7 load balancing and routes each request to the closest available backend. It offloads TLS for custom domains, supports built-in Web Application Firewall policies enforced at the edge, and can maintain user affinity by injecting a session cookie.

• A regional Azure Application Gateway still requires a separate gateway per region and does not offer global anycast entry points.
• Azure Traffic Manager is DNS-based; it cannot terminate TLS, apply a WAF policy, or maintain session affinity.
• Azure Load Balancer operates at layer 4 and cannot perform TLS offload, WAF inspection, or cookie-based affinity.

Enable Microsoft Entra (Azure AD) Kerberos authentication directly on the storage account. With Azure AD Kerberos, hybrid identities that exist in both on-premises AD DS and Microsoft Entra ID receive Kerberos tickets issued by Azure AD, letting users access SMB shares with their domain credentials. No storage account keys or SAS tokens are required. Shared keys and SAS rely on NTLM or token-based authentication rather than Kerberos, and private endpoints affect only network routing, not authentication.

The Azure Monitor agent (AMA) can be configured with a data collection rule to collect Syslog events and route the same data to multiple destinations-up to five Log Analytics workspaces or Event Hubs-at the same time. This lets you send the events to both the Microsoft Sentinel workspace and the IT operations workspace with a single agent on each server. The legacy Log Analytics (MMA/OMS) agent supports only one workspace on Linux, the Dependency agent is used for process-dependency mapping rather than log collection, and the Azure Diagnostics extension cannot forward Syslog to Microsoft Sentinel.

Defining an OAuth 2.0 authorization server in APIM that uses the authorization-code grant lets the developer portal obtain Microsoft Entra ID tokens on behalf of users without exposing a client secret in the browser. Adding the validate-azure-ad-token inbound policy causes the gateway to verify every JSON Web Token issued by Microsoft Entra ID, ensuring unauthenticated calls are blocked. The validate-content inbound policy, configured with a 128-KB size limit, rejects any oversized request body before the call reaches the backend. None of the alternative configurations satisfies all three requirements simultaneously: mutual TLS does not supply Entra ID tokens, IP filtering does not limit payload size, and the implicit grant exposes tokens directly in the browser without a secure back-channel exchange.

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.

A user-assigned managed identity is an independent Azure resource that can be attached to multiple other resources, including Function Apps that reside in different subscriptions. Because the identity is managed by Azure AD, credentials are automatically rotated, so no secrets need to be stored or updated. A system-assigned managed identity is tied to a single resource and cannot be shared, so you would have to create and grant access for two separate identities. An Azure AD application with a client secret requires manual secret storage and rotation, defeating the goal of minimal secret management. Shared access signature (SAS) tokens are not used for Azure Key Vault authentication and would require manual rotation as well.

To control the cryptographic parameters negotiated during tunnel establishment, Azure allows you to attach a custom IPsec/IKE policy to a site-to-site connection when the gateway is route-based. Creating and applying the policy lets you specify exact Phase 1 and Phase 2 algorithms, including AES256 encryption, SHA256 integrity, and DH Group 14. Policy-based traffic selectors influence which prefixes are advertised, but do not change cryptographic suites. Moving to active-active has no effect on algorithm selection, and switching to ExpressRoute eliminates the VPN altogether instead of securing it. Therefore, the correct first step is to define and assign a custom IPsec/IKE policy on the existing connection.

Azure DDoS Protection Standard is designed for internet-facing resources that could suffer large-scale network attacks and where rapid, SLA-backed mitigation, cost protection, and access to the DDoS Rapid Response team are valuable. A payment-processing web app exposed through public IP addresses matches these criteria. Development/test VMs, private-only endpoints, and workloads already fronted by a service such as Azure Front Door Premium either have lower risk or include their own edge-level protection, so purchasing the standalone DDoS Standard service is usually unnecessary.

Regional VNet Integration connects an App Service app to a subnet in the same region. Outbound traffic from the app to resources in that virtual network, such as an Azure SQL Managed Instance, is sent over private IP addresses and stays on the Microsoft backbone. Private Endpoint for the web app provides private inbound access to the app but does not make the app's outbound traffic private. Gateway-required VNet Integration uses a VPN gateway, is intended for cross-region scenarios, and is not needed here. A service endpoint for Microsoft.Sql secures traffic from a subnet to Azure SQL but does not apply to traffic that originates from an App Service app that is outside the virtual network.

Azure App Service lets you restrict the accepted TLS protocol versions at the platform level. In the TLS/SSL settings blade (or through the site configuration property "minTlsVersion") you can set the Minimum TLS Version to 1.2. The platform then terminates any connection using TLS 1.0 or 1.1 before it reaches the application, so no code changes are required and traffic continues to flow uninterrupted. Uploading a new certificate does not influence the protocol version that clients can negotiate, web.config rules only affect redirects and cannot disable older TLS handshakes, and inserting an Application Gateway is unnecessary extra infrastructure when the App Service platform natively enforces the policy.

The AWS Organization connector is initiated from the AWS management (payer) account and deploys an AWS CloudFormation StackSet that creates a single cross-account role in every existing member account, letting you onboard all 300 accounts in one operation. Although any future AWS accounts added to the organization must still be onboarded manually, this option is far less work than creating 300 individual single-account connectors or installing Azure Arc on every server. Azure Lighthouse cannot register AWS environments with Defender for Cloud.

Azure Virtual Network Manager (AVNM) lets you create a security admin configuration that contains security admin rules. These rules are evaluated before any NSG on the subnet or network interface; if an admin later changes or removes an NSG, the security admin rule is still enforced. Connectivity configurations only build peering topologies, an Azure DDoS plan cannot block specific TCP ports, and Application Security Groups rely on NSGs, which can be altered and therefore do not meet the requirement.

Choose the built-in cloud app named "Microsoft Azure Management." This app groups the Azure portal together with the main Azure Resource Manager management interfaces, including Azure PowerShell, Azure CLI, and the ARM REST API. Targeting it enforces the policy on the common Azure management paths while leaving other cloud apps-such as the Microsoft 365 workload apps-unaffected. Selecting "All cloud apps" would also catch the management endpoints but would unintentionally apply the policy to every application in the directory. The remaining options do not cover all required management methods.

Network Watcher packet capture lets you start an on-demand or scheduled trace that records packets as they enter or leave an Azure VM. The feature deploys a lightweight, Azure-managed extension automatically and does not require you to install or configure software inside the guest OS. IP flow verify only checks whether a flow is allowed or denied by NSG rules; it does not capture packets. Connection monitor measures connectivity and latency but provides no packet payloads. NSG flow logs record summary information about flows that cross an NSG, not the full packets themselves. Therefore, packet capture is the only option that meets the requirements.