Practice Test #6

Blob storage supports all three authentication methods with AzCopy: Azure AD, access keys, and SAS. - Azure AD: AzCopy can authenticate using OAuth tokens via "azcopy login". The identity must have appropriate RBAC data-plane roles such as Storage Blob Data Reader/Contributor/Owner. This is the preferred approach in the Azure Well-Architected Framework security pillar because it avoids long-lived shared secrets and supports least privilege. - SAS: You can append a SAS token to the blob/container URL. This is also common for automation and cross-tenant scenarios because it is scoped and time-limited. - Access keys: AzCopy can use the storage account key (for example via environment variables or connection strings). This works but is the least secure because keys provide broad access and require careful rotation. Therefore, the correct choice is the option that includes Azure AD, access keys, and SAS.

For Azure File storage, AzCopy authentication is typically done using either the storage account access key or a SAS token for the file share. - Access keys: AzCopy can authenticate to Azure Files using the account key, which authorizes operations against the file service endpoint. This is straightforward but is a shared-secret method with high privilege. - SAS: A share-level SAS can be used with the file share URL, providing time-bound and permission-scoped access, which is generally preferable to account keys for delegated access. - Azure AD: While Azure Files supports identity-based authorization for SMB access (via AD DS/Azure AD DS/Entra Kerberos depending on configuration), AzCopy does not use Azure AD OAuth in the same way as it does for Blob data operations in typical AZ-104 exam context. Thus, the best match for Azure Files with AzCopy is "Access keys and shared access signatures (SAS) only."

Changing the VM size modifies the VMSS model, and because the upgrade policy mode is Automatic, Azure applies that model change to existing instances automatically. However, automatic upgrades in a scale set are performed one update domain at a time to maintain availability, not across all instances at once. With four instances, the maximum number updated simultaneously is one. The other options are incorrect because 0 would apply to Manual mode, and 2 or 4 would imply larger concurrent batches than the automatic update-domain-based behavior used here.

A new build of the Windows Server 2016 platform image is an OS image update scenario, which is governed by the VMSS automatic OS image upgrade capability (AutomaticOSUpgradePolicy). The output shows EnableAutomaticUpdates is False in the WindowsConfiguration, and while an AutomaticOSUpgradePolicy object exists, there is no indication that automatic OS upgrades are enabled. In exam terms: if automatic OS upgrades are not enabled, Azure will not automatically roll out new platform image builds to existing VMSS instances. The instances keep running their current image version until you explicitly upgrade/reimage them (or otherwise trigger an upgrade process). Therefore, the new build will be deployed to up to 0 virtual machines automatically. Why others are wrong: B (1), C (2), and D (4) would only be possible if automatic OS image upgrades were enabled, in which case Azure would orchestrate upgrades in batches to preserve availability. Here, automatic OS image rollout is effectively disabled.

Correct answer: A (az). Because Computer1 already has the Azure CLI installed, the most direct and exam-expected way to install kubectl is to use the Azure CLI command that automates the download and installation. The Azure CLI executable is “az”, and AKS provides an “install-cli” helper under the “aks” command group. Why the others are wrong: - B (docker): Docker can run a container image that includes kubectl, but that’s not “installing the kubectl client on Computer1”; it’s an alternative execution method and not the standard AKS tooling installation approach tested in AZ-104. - C (msiexec.exe): msiexec installs MSI packages, but kubectl is not typically installed via an MSI from Microsoft as the primary AKS guidance; the exam expects Azure CLI usage. - D (Install-Module): This is a PowerShell cmdlet for installing PowerShell modules from repositories (e.g., Az module). kubectl is a standalone binary, not a PowerShell module.

Correct answer: A (aks). The full command to install kubectl via Azure CLI is “az aks install-cli”. Here, “aks” is the Azure CLI command group for Azure Kubernetes Service operations. The “install-cli” subcommand is specifically designed to install the Kubernetes command-line client (kubectl) on the local machine. Why the others are wrong: - B (/package): This resembles a parameter used with installers like msiexec, not with Azure CLI’s AKS commands. - C (-name): While “--name” is commonly used with many az commands (including AKS cluster operations), it is not part of the “az aks install-cli” syntax for installing kubectl. - D (pull): “pull” is associated with container image operations (e.g., docker pull) and is not relevant to installing kubectl through Azure CLI. Exam tip: Don’t confuse “az aks install-cli” (installs kubectl locally) with “az aks get-credentials” (configures kubeconfig to connect to a specific AKS cluster).

Pass is appropriate because the exhibits provide enough information to determine each outcome deterministically. Key facts visible in the images: - SSPR is enabled for “Selected” users and the selected group is Group2. - Enabled methods are only Mobile phone and Security questions. - Number of methods required to reset is set to 2. - Security questions require 3 correct answers to reset. - A note indicates admins are always enabled for SSPR and must use two methods. With these, you can evaluate each user based on group membership (User1 in Group1 only; User2 in Group2; User3 is an admin and in both groups) and then apply the method requirements. There’s no missing dependency (like licensing) required to answer the logic in this exam-style scenario.

User2 is a member of Group2, and SSPR is enabled for the selected group Group2, so User2 is in scope for self-service password reset. However, the authentication methods policy requires two methods to reset a password. Answering three security questions correctly satisfies only the security questions method, not the full reset requirement. Therefore, User2 cannot reset the password immediately after only answering the security questions and must complete a second allowed method such as mobile phone.

User1 is only a member of Group1, while SSPR is enabled only for the selected group Group2. Because User1 is not in scope for SSPR and does not hold an administrator role, she cannot use self-service password reset. In addition, the mobile phone app methods are not enabled in the authentication methods configuration; only Mobile phone and Security questions are enabled. Therefore, the statement is false.

User3 is a User administrator, which is a privileged Azure AD role. For administrator accounts, Azure AD SSPR requires two authentication methods and does not allow security questions as a reset method for admins. Although security questions are enabled for end users in the tenant, that setting does not apply to administrator password reset scenarios. Therefore, User3 cannot add security questions to the password reset process; admin users must use other allowed methods such as mobile phone or app-based methods if enabled.

Pass is appropriate because the recovery point count can be derived deterministically from the policy settings and the timeline. To solve these, you: 1) List all scheduled backup times that have occurred by the target timestamp. 2) Apply retention: daily points older than the daily retention window expire unless they are also marked for longer retention (weekly/monthly/yearly). 3) Count remaining unique recovery points. Here, the policy is clear (daily at 2:00 AM UTC; daily retention 5 days; weekly on Sunday). The target times (Jan 8 and Jan 15 at 14:00) are well after the 2:00 AM backups on those days, so the day’s backup has already occurred. Monthly/yearly settings don’t trigger within the first two weeks in a way that adds extra points. Therefore, the correct answers can be computed reliably.

By Jan 8 at 14:00 UTC, backups have run daily at 2:00 AM from Jan 1 through Jan 8 inclusive (8 total created). Now apply retention. Daily retention is 5 days, meaning only the last 5 daily recovery points remain as daily points: Jan 4, 5, 6, 7, and 8 (5 points). Weekly retention: every Sunday 2:00 AM backup is also retained as a weekly point for 20 weeks. In this period, Sunday is Jan 4. That recovery point (Jan 4 2:00 AM) is already included in the 5 daily points list, so it does not add an additional separate recovery point; it just ensures Jan 4 will remain available even after it ages out of daily retention. Therefore, the number of available recovery points on Jan 8 is 5.

By Jan 15 at 2:00 PM, backups have occurred daily from Jan 1 through Jan 15 at 2:00 AM. With 5-day daily retention, the daily points still retained are Jan 11, 12, 13, 14, and 15. Weekly retention keeps Sunday backups for 20 weeks, so Jan 4 is still available even though it is outside the daily retention window, while Jan 11 is already included in the daily-retained set. Monthly retention on day 2 preserves Jan 2, and yearly retention on Jan 9 preserves Jan 9, so the full set of unique retained recovery points is Jan 2, Jan 4, Jan 9, Jan 11, Jan 12, Jan 13, Jan 14, and Jan 15, which totals 8.