AZ-500 Practice Questions

The behavior described in the scenario is governed by the Azure Key Vault soft-delete feature, which is enabled by default.

• You can recover Policy1: No. Access policies are part of the Key Vault's configuration settings, not objects stored within it like keys or secrets. The soft-delete and recovery features do not apply to access policies. Once an access policy is deleted, it is permanently gone and cannot be recovered.
• You can add a new key named Item1: No. When a key (Item1) is deleted, it enters a soft-deleted state. While in this state, its name is reserved. You cannot create a new key with the same name until the soft-deleted item is either recovered or purged after its retention period expires.
• You can recover Item2: Yes. Secrets (Item2), like keys, are protected by the soft-delete feature. When Item2 is deleted, it is moved to a soft-deleted state for a specific retention period (typically 90 days), during which it can be fully recovered.

Microsoft Learn. (2023). Azure Key Vault soft-delete overview. This document explicitly states that soft-delete applies to keys, secrets, and certificates. It does not list access policies as recoverable objects. It also clarifies that "the names of its objects... are globally unique. You will not be able to add a key, secret, or certificate to a key vault with the same name as one in a soft-deleted state."

Microsoft Learn. (2023). az keyvault access-policy. The documentation for managing access policies via the Azure CLI (az keyvault access-policy delete) does not mention any recovery or soft-delete mechanism, confirming that the deletion is a permanent configuration change.

Every service- and account-level SAS or stored-access-policy signature for a Storage account is produced by hashing the request with either the primary or the secondary account key. When you regenerate an account key, its value changes; any signature that was computed with the old value can no longer be validated by Azure Storage. Consequently, all requests to the Blob and File services that rely on those SAS tokens fail, effectively revoking every previously issued SAS. Because the scenario only mentions SAS-based access, regenerating both keys blocks all unauthorized access to sa1 and fulfils the goal.

B. Regenerating the keys is the documented immediate method for invalidating all existing SAS; therefore, the solution does meet the goal.

1. Microsoft Docs – “Secure access to data in Azure Storage: Revoking a SAS” (v2023-08-01)

§“Revoke a SAS by rotating the account key”. https://learn.microsoft.com/azure/storage/common/storage-sas-overview

2. Microsoft Docs – “Manage storage account access keys” (v2023-07-31)

§“Regenerate access keys”. https://learn.microsoft.com/azure/storage/common/storage-account-keys-manage

3. Microsoft Docs – “Grant limited access to Azure Storage resources using shared access signatures”

§“Effect of key rotation on existing SAS”. https://learn.microsoft.com/azure/storage/common/storage-shared-access-signature

(Each reference states that rotating either account key immediately invalidates every SAS signed with that key.)

The proposed solution using Password Hash Synchronization (PHS) and Seamless SSO does not meet all the stated requirements. While PHS is the most lightweight option in terms of server infrastructure, it does not enforce all on-premises Active Directory policies in real-time for cloud authentications.

Specifically, user logon limitations such as logon hours are not enforced by PHS because the authentication occurs against the password hash stored in Azure AD, not directly against the on-premises Active Directory. To enforce real-time policies like logon hours and ensure that password expiration policies are checked directly against the on-premises domain, Pass-through Authentication (PTA) or Active Directory Federation Services (AD FS) would be required. Therefore, the solution fails to meet the goal.

A. Yes: This is incorrect because the solution fails to enforce critical on-premises security policies like logon hours for cloud authentications, which is a specific requirement of the integration strategy.

1. Microsoft Entra documentation

"Choose the right authentication method for your Microsoft Entra hybrid identity solution

" Microsoft Learn. In the "Sign-in method comparison" table

the row for "Enforce on-premises user account policies (for example

logon hours)" clearly states "No" for Password hash synchronization and "Yes" for Pass-through authentication and Federation. This directly confirms that the proposed solution does not meet the requirement.

2. Microsoft Entra documentation

"What is password hash synchronization with Microsoft Entra ID?

" Microsoft Learn. This document explains that PHS synchronizes a hash of the password. It notes that some attributes like userAccountControl (which includes account disabled status) are synchronized

but it does not provide a mechanism for real-time policy checks like logon hours.

3. Microsoft Entra documentation

"Microsoft Entra Pass-through Authentication: How it works

" Microsoft Learn. This document details how PTA validates credentials directly against on-premises Active Directory. Section "How it works: Detailed description" explains that the on-premises Authentication Agent receives the request and validates it against Active Directory

which is the mechanism that allows for the enforcement of on-premises policies like account status

password validity

and logon hours.

Azure Key Vault–backed features (for example, Azure Disk Encryption, certificate/secret retrieval through a managed identity, or a disk-encryption set) can be used by any Azure virtual machine whose operating system is on Microsoft’s supported-OS list:

• Windows Server 2008 R2 SP1 or later

• Modern Linux distributions on kernel 3.4 +

The scenario gives four VMs (VM1-VM4) and imposes a requirement that the VM(s) hosting App1 must be able to integrate with KeyVault1. Because every listed VM meets the supported-OS requirement and any Azure VM can be enabled for a system-assigned managed identity and granted access policies in Key Vault, all four VMs are suitable. Selecting the complete set (VM1, VM2, VM3, VM4) satisfies the Key Vault technical constraint while not excluding capacity, availability-zone, or scale considerations.

A. Ignores other equally capable VMs, limiting capacity and resiliency.

B. Omits VM3 & VM4, unnecessarily reducing availability and scale.

C. Excludes VM3, breaking potential zone-redundancy and capacity goals.

1. Microsoft Azure – “Azure Disk Encryption overview”

Supported operating systems section (Docs ID: azure/virtual-machines/disk-encryption-overview)

2. Microsoft Azure – “Use managed identities to access Azure Key Vault”

Prerequisites and Supported resources sections (Docs ID: azure/key-vault/general/about-managed-identity)

3. Microsoft Azure – “Azure Key Vault best practices”

Security Baselines → Virtual Machines can access Key Vault through managed identities (Docs ID: azure/key-vault/general/best-practices)

To enable Azure AD Privileged Identity Management (PIM), an administrator must first onboard the service for the tenant. This initial setup process follows a specific sequence.

1. Sign up PIM for Azure AD roles: The first step is to navigate to the PIM service in the Azure portal and explicitly sign up or enable it for your Azure AD tenant. This action provisions the PIM service.
2. Consent to PIM: After signing up, a consent prompt appears. A user with Global Administrator privileges must grant permissions for the PIM service to manage roles within the Azure AD tenant.
3. Verify your identity by using multi-factor authentication (MFA): Consenting to PIM is a highly privileged action. To ensure security, Azure requires the administrator granting consent to verify their identity using MFA. This check is an integral part of the consent process.

The other actions, "Discover privileged roles" and "Discover resources," are management tasks performed after PIM has been successfully set up and onboarded.

Microsoft Learn, "Start using Privileged Identity Management." This official documentation outlines the onboarding process. It states, "To get started with Privileged Identity Management in your Azure Active Directory (Azure AD) organization, you must first enable it for your tenant...When you enable Privileged Identity Management for your directory, you are prompted to consent...To consent to Privileged Identity Management, you will be asked to validate your identity with multi-factor authentication." This confirms the sequence of signing up, consenting, and verifying with MFA.

Microsoft Learn, "Discover Azure resources to manage in Privileged Identity Management." This document explains that discovering resources is a subsequent step. The introduction states, "Once you have set up Privileged Identity Management (PIM) for your organization, you can begin to manage access to Azure resources." This clarifies that resource discovery happens after the initial setup described in the correct answer.

Both the creation of a new Organizational Unit (OU) and a new user account within an on-premises Active Directory Domain Services (AD DS) domain are tasks performed using on-premises management tools.

• OU2: An Organizational Unit is a container object that exists only within an on-premises AD DS. Therefore, it must be created and managed using a tool that directly interfaces with the on-premises domain controllers. Active Directory Users and Computers (ADUC) is the standard, long-standing Microsoft Management Console (MMC) snap-in for this purpose.
• User1: Since User1 is being created within an OU in the on-premises domain, its source of authority is the on-premises AD DS. Even if this user will be synchronized to Azure AD later, the initial creation and management of core attributes must happen on-premises. Active Directory Users and Computers is the appropriate tool for creating user accounts in AD DS.

The Azure portal is used for managing cloud-native Azure AD objects, and Azure AD Connect is a synchronization service, not a direct management tool.

Microsoft Learn, Active Directory Users and Computers Documentation: "Active Directory Users and Computers is a Microsoft Management Console (MMC) snap-in that you use to administer Active Directory (AD). You can manage AD objects, such as users, groups, computers, printers, and organizational units (OUs)."

Microsoft Learn, Create a New User Account: This document details the step-by-step process of creating a user account within an on-premises domain, explicitly stating the use of the "Active Directory Users and Computers" tool.

Microsoft Entra ID Documentation, Hybrid Identity: "When you synchronize Active Directory Domain Services (AD DS) to Microsoft Entra ID, you must create and manage users and groups on your on-premises servers. You can't create or manage them directly in Microsoft Entra ID." This confirms that objects originating from on-premises AD DS must be managed using on-premises tools.

The goal is to enable authentication to an Azure HDInsight cluster using on-premises Active Directory credentials. This is achieved by using the HDInsight Enterprise Security Package (ESP), which allows the cluster to be joined to an Active Directory domain.

Azure Active Directory Domain Services (Azure AD DS) provides managed domain services (like Kerberos, NTLM, and LDAP) in Azure. In a hybrid identity scenario, Azure AD Connect synchronizes user identities and password hashes from on-premises AD to Azure AD. Azure AD DS then synchronizes these identities from Azure AD.

By deploying Azure AD DS and joining the HDInsight ESP cluster to this managed domain, users can authenticate using their synchronized on-premises credentials. Therefore, the proposed solution is correct.

B. No: This option is incorrect. Deploying Azure AD DS is a standard and officially documented method for enabling domain-join capabilities for services like HDInsight, which in turn allows authentication with on-premises credentials in a hybrid setup.

1. Microsoft Docs

"Plan for Azure HDInsight clusters with Enterprise Security Package": This document outlines the prerequisites for using ESP. It explicitly states

"ESP clusters require Azure AD DS... If you're using Azure Active Directory Domain Services (Azure AD DS)

then Azure AD Connect synchronizes on-premises identities to Azure AD. This is a prerequisite for ESP clusters." This confirms that Azure AD DS is the required component for this scenario.

2. Microsoft Docs

"What is Azure Active Directory Domain Services?": This document explains the function of Azure AD DS. Under the "How does Azure AD DS work?" section

it details that "Azure AD DS integrates with your Azure AD tenant... This integration lets users sign in to services and applications connected to the managed domain using their existing credentials." This supports the solution's mechanism.

3. Microsoft Docs

"Configure HDInsight clusters with Enterprise Security Package by using Azure Active Directory Domain Services": This tutorial provides a step-by-step guide for implementing the exact solution proposed. The introduction states

"In this article

you learn how to create and configure an Azure HDInsight cluster with Enterprise Security Package (ESP) by using Azure Active Directory Domain Services (Azure AD DS)." This serves as a practical confirmation of the solution's validity.

To allow RDP connections from the internet to a virtual machine (VM1) that only has a private IP address, you must introduce a service that has a public IP and can forward traffic to the private VM. Azure Firewall is designed for this purpose using Destination Network Address Translation (DNAT).

1. Create a new subnet: Azure Firewall requires its own dedicated subnet. This subnet must be named AzureFirewallSubnet. Therefore, creating this specific subnet is the first necessary step.
2. Deploy Azure Firewall: Once the dedicated subnet is available, you can deploy the Azure Firewall into it. The firewall will be provisioned with a public IP address, which will serve as the public endpoint for incoming RDP connections.
3. Create a NAT rule collection: After the firewall is deployed, you must configure a DNAT rule to tell the firewall how to handle the incoming RDP traffic. This is done by creating a NAT rule collection. The rule will specify that any traffic destined for the firewall's public IP on the RDP port (TCP/3389) should be translated and forwarded to VM1's private IP address on the same port.

This sequence correctly establishes a secure path from the internet to the private virtual machine.

Azure Firewall deployment prerequisites: The official Microsoft documentation states, "Azure Firewall must be deployed in a dedicated subnet. The subnet name must be AzureFirewallSubnet...". This confirms that creating the specific subnet is the initial requirement.

Microsoft Learn, Tutorial: Deploy and configure Azure Firewall and policy using the Azure portal, "Create a VNet" section.

Azure Firewall DNAT feature: The documentation explains how to use DNAT to translate inbound internet traffic. "You can configure Destination Network Address Translation (DNAT) to translate and filter inbound Internet traffic to your subnets... In Azure Firewall, a NAT rule collection is used to define the rules for DNAT." This supports the final step of creating a NAT rule collection.

Microsoft Learn, Filter inbound traffic with Azure Firewall DNAT using the Azure portal.

The settings for managing application registrations and user consent are located in distinct areas within the Azure Active Directory portal, reflecting their different purposes.

• Registration Settings: The ability for non-administrator users to register custom-developed applications is a tenant-wide policy. This setting, "Users can register applications," is configured under the general Azure AD > User settings blade. This controls the creation of application objects in the directory.
• Consent Settings: The framework governing how and if users can permit applications (both custom and third-party) to access company data on their behalf is managed under Enterprise Applications. These settings, such as "Users can consent to apps accessing company data on their behalf," are configured on the Enterprise Applications > User settings blade (specifically within the "Consent and permissions" section). This relates to the service principal object and its permissions within the tenant.

Microsoft Learn | Azure Active Directory Documentation:

Registration Settings: In the document "Quickstart: Register an application with the Microsoft identity platform," the prerequisites section guides the administrator to Azure Active Directory > User settings to ensure the "Users can register applications" setting is enabled.

Consent Settings: The article "Configure how users consent to applications" explicitly states to navigate to Azure Active Directory > Enterprise applications > Consent and permissions > User consent settings to manage these configurations. The "User settings" blade within "Enterprise applications" is the location for these controls.

To authorize an Azure identity, such as the service principal used by an Azure Kubernetes Service (AKS) cluster, to access an Azure resource like an Azure Container Registry (ACR), you must use Azure Role-Based Access Control (RBAC). The correct procedure is to create a role assignment. This assignment links the identity (the AKS service principal), a role definition that specifies permissions (e.g., AcrPull), and the scope (the specific ACR instance). This grants the AKS identity the required permissions to pull container images from the registry without managing explicit credentials like passwords or keys.

A. an Azure AD user: An Azure AD user is an identity for a person. The question requires using the AKS cluster's non-human service principal identity.

B. a secret in Azure Key Vault: While Key Vault stores secrets, it does not grant permissions. The fundamental step is to assign a role to the service principal to authorize its access.

C. an Azure AD group: Creating a group is for managing identities, but it does not grant permissions on its own. A role assignment would still be required for the group.

1. Microsoft Docs

"Authenticate with Azure Container Registry from Azure Kubernetes Service": This document explicitly states the procedure. Under the section "Configure ACR integration for existing AKS clusters

" it details the process for service principals: "To grant the service principal access to your ACR

you need to assign a role to the service principal for your ACR." It then provides the az role assignment create command as the solution.

Source: https://learn.microsoft.com/en-us/azure/aks/cluster-container-registry-integration?tabs=azure-cli#configure-acr-integration-for-existing-aks-clusters

2. Microsoft Docs

"What is Azure role-based access control (Azure RBAC)?": This document defines the core components of Azure RBAC. It explains

"A role assignment is the process of attaching a role definition to a user

group

service principal

or managed identity at a particular scope for the purpose of granting access." This confirms that a role assignment is the object you create to grant access.

Source: https://learn.microsoft.com/en-us/azure/role-based-access-control/overview#role-assignments

3. Microsoft Docs

"Azure Container Registry roles and permissions": This page lists the built-in roles for ACR

such as AcrPull. It clarifies that these roles are assigned to "a user

group

service principal

or managed identity to grant them permissions to ACR." This reinforces that a role assignment is the mechanism to apply these permissions.

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