Microsoft Azure Administrator Associate Practice Test (AZ-104)

Group-based licensing in Azure Entra ID allows administrators to assign licenses to all members of a security group. This means that when users are added to or removed from the group, licenses are automatically assigned or revoked accordingly, streamlining the license management process.

Integrating the storage account with Azure Active Directory (Azure AD) allows the company to assign permissions to users through role-based access control (RBAC) without sharing access keys. This enhances security by managing permissions centrally and reduces the risk associated with key distribution. Using Shared Access Signatures involves generating tokens that could be misused if shared improperly. Distributing access keys compromises the security of the entire storage account, and connection strings do not provide a method for assigning user-specific permissions.

Roles in Azure can be assigned at various scopes, including the subscription level. Assigning a role at the subscription level grants permissions to all resources within that subscription. Therefore, roles can be assigned at the subscription level to manage access to all resources, making the statement false.

This statement is true. In Azure Entra ID, you can create security groups that include other groups as members, enabling nested group configurations. This feature simplifies management by allowing administrators to assign permissions and access to a parent group, which automatically applies to all nested groups and their users.

Assigning the Contributor role at the resource group level grants the contractor the ability to manage resources within that resource group without allowing them to modify access permissions. This adheres to the principle of least privilege by providing only the necessary permissions. Assigning the Owner role would allow the contractor to alter access permissions, which is not desired. Assigning roles at the subscription level would grant access beyond the intended scope.

The Archive access tier is designed for data that is rarely accessed and can tolerate retrieval latency of several hours. It offers the lowest storage costs among the tiers, making it ideal for minimizing costs for long-term retention of infrequently accessed data required for compliance.

The Cool tier is suitable for infrequently accessed data that requires immediate (< milliseconds) retrieval, but its storage costs are higher than the Archive tier. The Hot tier has the highest storage costs and is intended for frequently accessed data, which does not align with the scenario. The Premium tier provides high-performance storage at a higher cost and is not appropriate for rarely accessed data where cost minimization is a priority.

The first action is to create a Recovery Services vault. The Recovery Services vault is a management entity that stores recovery points created over time and provides an interface to perform backup-related operations. Without creating the vault, you cannot proceed to configure backup policies or register your virtual machines for backup. Options like configuring backup policies or installing agents are subsequent steps after the vault is in place. Enabling Azure Site Recovery is related to disaster recovery, not the initial backup configuration.

A Private Endpoint enables a private and secure connection between your virtual network and an Azure service powered by Azure Private Link. This keeps the traffic within the Azure backbone network, eliminating exposure to the public internet and enhancing security.

Network Watcher Connection Monitor is the correct tool because it allows administrators to monitor connectivity between Azure resources and external endpoints over time, providing continuous insights into connection health, latency, and packet loss. IP Flow Verify is used to check whether traffic is allowed or denied based on security rules for a specific flow but does not provide ongoing monitoring. Traffic Analytics analyzes network traffic flow logs for insights and trends but doesn't test connectivity to specific endpoints. NSG Flow Logs capture information about ingress and egress IP traffic through Network Security Groups but do not actively test or monitor connectivity health.

To grant users the ability to read and write blobs without delete permissions, you need to create a custom role that includes the read and write actions but excludes the delete action. Assigning this custom role to the users via role-based access control (RBAC) ensures they have the exact permissions required. The built-in Storage Blob Data Contributor role grants read, write, and delete permissions, which is more than what's needed. The Storage Blob Data Reader role only allows reading blobs, not writing them. Enabling identity-based access does not address the specific permission settings required in this scenario.

By creating a shared access signature (SAS) associated with a stored access policy on the container, you can grant the vendor temporary access and retain the ability to revoke that access by modifying or deleting the policy. This approach doesn't require regenerating storage account keys and doesn't affect other services. Generating a SAS token without a stored access policy doesn't allow you to revoke access until it expires. Adding the vendor as a contributor provides broader access than necessary and complicates permissions management. Sharing the storage account access keys grants full access to the account, which is a security risk and revoking access would impact all services using those keys.

Utilizing group-based licensing is the most efficient method for managing licenses at scale in Azure AD. When you assign licenses to a group, all members of that group automatically receive the licenses, and they are removed when users leave the group. This streamlines the process of onboarding and offboarding employees without the need for manual intervention each time. Assigning licenses to individual users manually is not practical for a large number of employees and increases administrative overhead. Administrative units are used to delegate administrative permissions and scope management tasks but do not facilitate automatic license assignment. Enabling self-service licensing allows users to request licenses themselves; however, this approach may not align with organizational policies requiring control over license distribution and does not automate license revocation when users leave.

To add a data disk to VM1 without causing downtime, you can attach an empty managed data disk to the VM using the Azure portal. This operation can be performed while the VM is running and does not require stopping or deallocating the VM. Stopping or deallocating the VM (as in options B and C) would cause downtime, which is not acceptable in this scenario. Redeploying VM1 with a larger OS disk size (option D) does not add a separate data disk and could result in downtime and potential data loss.

Resource locks prevent resources from being modified or deleted, including moving them to a different resource group. If VM1 or its associated resources have locks applied, the move operation will fail. By removing any resource locks from VM1 and its related resources, you can successfully complete the move. Deallocating the VM is not required for moving it between resource groups within the same subscription and region. Changing the location of VM1 is not possible without recreating it in a different region, and adjusting user permissions is unnecessary if you already have the required access.

To meet these requirements, you should create a new backup policy that schedules backups outside business hours and sets the retention period to 30 days. This ensures that daily backups are taken without affecting system performance during peak times, and that backups are retained for the required period. Modifying the existing backup policy to increase retention to 90 days and scheduling backups during peak hours does not meet the requirement of minimal impact during business hours and unnecessarily extends retention. Using the default backup policy without changes may not align with the specific scheduling and retention requirements. Creating a policy with weekly backups would not allow recovery of daily data.