AZ-104 Practice Exam — AZ-104：Azure Administrator Associate

The scenario specifies all virtual machines are already deployed into a single existing resource group RG1, and the only requirement is to associate each VM with its corresponding department for organizational purposes. The suggested answer of assigning tags directly to the VMs is the optimal solution because tags are designed to add custom, organization-specific metadata to individual Azure resources without requiring changes to existing resource grouping structures. This approach meets the requirement with minimal administrative overhead, and also enables additional use cases such as per-department cost reporting, policy filtering, and resource sorting that align with Azure administration best practices tested in the AZ-104 exam. Option Analysis: A. Incorrect. Azure Management Groups are a high-level governance scope used to organize multiple Azure subscriptions, apply policies, and manage access across large sets of subscriptions. They operate far above the individual VM resource level, and cannot be used to associate individual VMs with specific departments, so this does not address the scenario requirement. B. Incorrect. While resource groups can be used to group resources by department, the scenario explicitly states all VMs are already located in RG1. Creating new resource groups would require migrating existing VMs, which introduces unnecessary administrative effort and changes to the existing deployment structure that are not required to simply associate VMs with their departments. C. Correct. Azure tags are custom key-value pairs that can be applied directly to individual resources including virtual machines. You can create a tag with a key such as "Department" and values matching each department name, then assign the appropriate tag value to each VM. This directly associates each VM with its department without modifying the existing resource group structure, perfectly meeting the scenario requirement. This is the standard recommended approach for resource categorization tested in AZ-104. D. Incorrect. There is no native, built-in department attribute in standard virtual machine configuration settings. Modifying general VM settings refers to adjusting configurations such as VM size, disk configurations, or network settings, none of which are designed to store organizational department association data. This option is vague and does not follow Azure administration best practices for this use case. Key Concepts: 1. Azure Resource Tagging: Tags are customizable key-value metadata pairs applied to Azure resources to add organizational context. They support use cases including resource categorization, cost allocation, policy scoping, and audit reporting, and can be applied at the individual resource level without changing higher-level resource grouping structures. 2. Azure Resource Scope Hierarchy: The Azure governance and resource hierarchy follows the structure of Management Groups > Subscriptions > Resource Groups > Individual Resources. Each scope serves a specific purpose: management groups for cross-subscription governance, resource groups for lifecycle management of related resources, and tags for fine-grained, resource-level categorization within existing scopes. 3. Azure Resource Organization Best Practices: Tags are the recommended first approach for adding custom organizational attributes to resources when you do not need to separate resources for access control or lifecycle management purposes, as they eliminate the need to restructure existing resource group or subscription deployments. References: Use tags to organize your Azure resources and management hierarchy, https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/tag-resources Organize your Azure resources, https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-setup-guide/organize-resources

The scenario requires an access policy with three core mandatory components: first, it must target only members of the Global Administrators group, second, it must only apply when users connect from untrusted locations, and third, it must require both Multi-Factor Authentication (MFA) and an Azure AD-joined device for successful access. The proposed solution modifies settings via the legacy multi-factor authentication user settings page. This legacy configuration interface only supports enabling or disabling per-user MFA for all access contexts, with no functionality to configure granular conditions like location filters, device state requirements, or combined access controls. The proposed solution cannot enforce the Azure AD-joined device requirement, cannot scope the rule to only trigger for untrusted locations, and thus fails to meet the stated requirements. The correct method to implement this set of controls is to create an Azure AD Conditional Access policy that defines the targeted group, location condition, and combined grant controls for MFA and Azure AD joined devices. Option Analysis: A. This option is incorrect. Modifying per-user MFA settings only enforces MFA for affected users in all access scenarios, regardless of location or device state. It does not support restricting the rule to untrusted locations, nor can it require users to use an Azure AD-joined device as a condition for access, so it fails to meet two of the three core requirements of the scenario. B. This option is correct. The combination of targeted group scope, location-based triggering, and dual requirements for MFA and Azure AD joined device access controls can only be implemented using Azure AD Conditional Access policies. The proposed solution uses the legacy MFA user configuration page, which lacks support for the required granular conditions and access controls, so it does not satisfy the stated goal. Key Concepts: 1. Azure AD Conditional Access Policies: A core Azure AD identity governance feature that allows administrators to combine signals including user group membership, network location, device state, and accessed resource to enforce granular access controls. This is the only supported tool to implement the combined requirements in the scenario. 2. Per-User Multi-Factor Authentication: A legacy MFA configuration method that enforces MFA for individual users across all access contexts, with no support for conditional triggers like location or device requirements. This method is not appropriate for context-aware access rules. 3. Conditional Access Grant Controls: Access requirements that must be satisfied for a user to be granted access to a resource, including controls for requiring MFA, requiring an Azure AD joined device, or requiring a compliant device. Multiple grant controls can be combined in a single Conditional Access policy to meet custom access requirements. References: 1. What is Conditional Access in Azure Active Directory?, https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/overview 2. Enable per-user Azure AD Multi-Factor Authentication to secure sign-ins, https://learn.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-userstates

The scenario requires two specific security requirements for Global Administrators accessing Azure AD from untrusted locations: mandatory Multi-Factor Authentication (MFA) and mandatory use of an Azure AD-joined device. Both of these requirements are enforced using Conditional Access grant controls, which run during the authentication phase to determine if a user is permitted to access the target resource. Session controls, by contrast, are applied after a user has already been granted access, and govern properties of the active session such as session duration, persistent access permissions, or application-specific feature restrictions. Modifying only session controls as described in the solution does not configure the required grant controls for MFA and Azure AD joined device enforcement, so the solution fails to meet the stated goal. Option Analysis: A. This option is incorrect. The required policy configurations (enforce MFA, enforce Azure AD joined device usage) are grant control settings, not session control settings. Altering session controls alone cannot implement the required security rules, so the solution does not satisfy the requirements. B. This option is correct. The solution targets the wrong category of Conditional Access controls. To implement the required MFA and device state requirements, you must modify the grant control settings of the Conditional Access policy, not the session control settings as outlined in the proposed solution. Key Concepts: 1. Conditional Access Grant Controls: These are authentication-phase access controls that determine if a user is allowed access to a target resource. Common grant controls include requiring MFA, requiring a compliant or Azure AD joined device, requiring a password change, or blocking access entirely. 2. Conditional Access Session Controls: These are post-authentication access controls that limit actions or duration within an active user session. Examples include sign-in frequency limits, persistent browser session settings, and real-time session monitoring via Microsoft Cloud App Security integration. 3. Conditional Access Policy Structure: All Conditional Access policies follow a standard structure of assignments (which users/groups, cloud apps, and conditions such as location trigger the policy) and access controls (either grant or session controls that are enforced when the policy conditions are met). References: Conditional Access Grant Controls, https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/concept-conditional-access-grant Conditional Access Session Controls, https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/concept-conditional-access-session

The scenario requires an Azure AD Conditional Access policy that enforces two specific access requirements for members of the Global Administrators group accessing Azure AD from untrusted locations: Multi-Factor Authentication (MFA) and use of an Azure AD-joined device. Azure AD Conditional Access policies have two core functional sections: assignments, which define the target users, target resources, and triggering conditions (including untrusted location rules) that activate the policy, and grant controls, which define the mandatory requirements a user must satisfy to be granted access when policy conditions are met. Both required controls for this use case, require MFA and require Azure AD-joined device, are configured directly in the grant control section of the policy. Altering the grant control settings to enable both requirements meets the stated policy goals, assuming the policy assignments (targeting Global Administrators, Azure AD as the target resource, and untrusted locations as the triggering condition) are already configured as part of the base policy setup. Option Analysis: A. Correct: The grant control pane in Azure AD Conditional Access policies is the dedicated configuration location for access enforcement requirements, including both MFA and device state requirements such as requiring an Azure AD-joined device. Modifying this section to enable both required controls implements the exact policy rules specified in the scenario, so the solution meets the goal. B. Incorrect: No alternative configuration section is required to set the specified access requirements. All mandatory enforcement rules for this use case are configured exclusively within the grant control settings of the Conditional Access policy, so the described solution is sufficient to meet the stated requirements. Key Concepts: 1. Conditional Access Grant Controls: This core Conditional Access policy component defines mandatory access requirements users must fulfill to be granted access to target cloud resources, including MFA, device compliance, Azure AD joined device, and approved client app requirements. 2. Conditional Access Location Conditions: Administrators can define named locations and classify networks as trusted or untrusted, which serve as triggering conditions to apply specific grant controls for high-risk access scenarios like privileged user access from external networks. 3. Privileged Account Security Controls: Enforcing MFA and managed device requirements for Global Administrators and other privileged Azure AD roles is a foundational Azure security best practice, designed to mitigate the risk of unauthorized access to highly privileged administrative accounts. References: Conditional Access Grant Controls, https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/concept-conditional-access-grant Secure Azure AD administrator roles with Conditional Access, https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/howto-conditional-access-policy-admin-mfa

The scenario requires a custom Ubuntu Server VM deployment that includes adding a trusted root CA during provisioning. This use case relies on native support for injecting custom OS configuration during initial VM creation, which is optimized for Linux VMs via cloud-init, the standard Azure Linux provisioning tool. The az vm create command from the Azure CLI provides a streamlined, single-command workflow to pass cloud-init configuration directly via the --custom-data parameter, which can include the exact steps to add the required trusted root CA to the Ubuntu OS during deployment. This eliminates the need for separate pre-configuration or post-deployment steps, fully aligning with the custom deployment requirement specified, and matches the Azure deployment best practices tested in the AZ-104 exam. Option Analysis: A. The New-AzureRmVm cmdlet: Incorrect. The AzureRM PowerShell module is fully deprecated and no longer supported by Microsoft for current Azure deployments. The AZ-104 exam exclusively tests the modern Az PowerShell module, not legacy AzureRM cmdlets, so this option is invalid for production or exam use cases. B. The New-AzVM cmdlet: Incorrect. While New-AzVM is the valid current Az PowerShell cmdlet for VM creation, it does not support direct injection of custom provisioning data as part of a single creation command. To add custom configuration like a trusted root CA with New-AzVM, you must first build a complete VM configuration object with separate cmdlets such as Set-AzVMOperatingSystem to attach custom data before running New-AzVM, making it far less streamlined for the required custom deployment than the Azure CLI option. C. The Create-AzVM cmdlet: Incorrect. No such cmdlet exists in either the legacy AzureRM or modern Az PowerShell modules. This is a distractor option designed to test knowledge of valid Azure PowerShell cmdlet naming conventions, which follow the approved Verb-Noun format with standard approved verbs like New, not Create for resource creation. D. The az vm create command: Correct. This is the official Azure CLI command for virtual machine creation, and it natively supports the --custom-data parameter to pass cloud-init configuration scripts for Linux VM customization during initial provisioning. You can embed the steps to add the trusted root CA directly in the cloud-init script passed to this command, fulfilling the custom deployment requirement in a single, simple command, which is the recommended approach for this Linux deployment scenario per Azure best practices covered in AZ-104. Key Concepts: 1. Linux VM Provisioning with Cloud-Init: Azure Linux VMs including Ubuntu use cloud-init as the default provisioning agent to apply OS customizations during deployment, such as adding trusted CAs, creating users, or installing packages, without post-deployment manual configuration. 2. Azure Management Tooling Proficiency: The AZ-104 exam tests knowledge of valid, supported Azure management tools, including the difference between deprecated AzureRM PowerShell cmdlets, modern Az PowerShell cmdlets, and Azure CLI commands, plus their respective use cases for resource deployment. 3. Custom Data Injection for VMs: Custom data is payload passed to Azure VMs during creation to run first-boot provisioning logic. Support for custom data injection varies by management tool, with the Azure CLI offering the most simplified workflow for Linux custom deployments via the built-in --custom-data flag for az vm create. References: Quickstart: Create a Linux virtual machine in Azure with the Azure CLI, https://learn.microsoft.com/en-us/azure/virtual-machines/linux/quick-create-cli Cloud-init support for virtual machines in Azure, https://learn.microsoft.com/en-us/azure/virtual-machines/linux/using-cloud-init