Deploy and Manage Azure Compute practice questions

Standard HDD

Why wrong: Standard HDD is a magnetic spindle-based disk that offers the lowest storage cost but suffers from high rotational latency (often tens of milliseconds) and limited IOPS, typically capped at a few hundred per disk. For an application that writes heavily, this will produce severe write bottlenecks and poor response times, so it is unsuitable. While it can handle infrequent reads or writes in dev/test scenarios, it completely fails the 'heavy write' and low-latency requirement of this scenario.

Standard SSD

Why wrong: Standard SSD uses flash-based media and provides a moderate balance of price and performance, but its per-disk IOPS and throughput are noticeably lower than Premium SSD v2, and it often relies on burst behavior for short periods of elevated activity. Under a sustained heavy write load, once the burst budget is exhausted, performance degrades substantially, leading to inconsistent latency and throughput. This makes it incorrect for an application that continuously writes large volumes of data and requires stable, high-performance storage.

Premium SSD v2

Why wrong: Premium SSD v2 is the correct choice for a write-heavy application because it delivers sub-millisecond latency and consistent, highly scalable IOPS that are critical for sustained write-intensive workloads. Unlike lower tiers, it allows you to provision IOPS and throughput independently, so you can size performance to match your write volume without over-provisioning storage. Azure documents that Premium SSD v2 is optimized specifically for production workloads that demand both high IOPS and low jitter, making it the only option here that meets the stated performance requirement.

Boot diagnostics

Why wrong: Boot diagnostics is incorrect because it is a troubleshooting feature that captures serial console output and screenshots of a VM during the boot process. It helps administrators diagnose startup failures, blue screens, or kernel panics, but it has no mechanism to execute arbitrary scripts, scheduled or otherwise. Its sole purpose is to provide visibility into the boot sequence, not to manage or configure the guest OS after boot.

Azure Policy

Why wrong: Azure Policy is incorrect because it is a governance and compliance service that enforces rules on Azure resources at the control plane level. While a policy can audit or apply settings like allowed VM sizes or enforce the presence of certain extensions, it does not run scripts inside a guest OS on a schedule. Policy evaluation occurs during resource creation and on a periodic compliance cycle, but it is not a scripting or task-scheduling engine for VM guest operating systems.

An availability set

Why wrong: An availability set is incorrect because it is a logical grouping of VMs that spreads them across fault domains and update domains to protect against hardware failures and planned maintenance. It is purely a high-availability and resilience construct and has no role in configuration automation or script execution. Placing VMs in an availability set does not affect what runs inside those VMs; it only determines how the underlying infrastructure is arranged.

Use an ephemeral OS disk to reduce storage cost.

Why wrong: Ephemeral OS disks are stored on the local VM host and use local temporary storage rather than Azure-managed persistent storage. Any event that causes the VM to move to another host, such as a deallocation/start, service healing, or reimage, permanently deletes the OS disk. Consequently, they are ideal for stateless workloads like image caches or scale-set nodes, but they explicitly violate the requirement that the OS disk survive host moves. Using an ephemeral disk to reduce cost would sacrifice durability and could result in full data loss.

Use an unmanaged VHD stored in a storage account.

Why wrong: Unmanaged VHDs in a storage account are a legacy disk management model that requires you to create and maintain a storage account to hold the .vhd blob, set capacity quotas, and manually handle replication settings. Managed disks abstract these details and provide better integration with availability sets, snapshots, and encryption. Although unmanaged disks technically persist across host moves, they are operationally heavier and inconsistent with a cost-aware, modern Azure deployment; managed disks offer simpler lifecycle management and often lower total cost when you consider administrative overhead. The scenario asks for a cost-constrained, simple design, so choosing an unmanaged VHD introduces unnecessary complexity.

Use a Generation 1 image and enable Secure Boot after deployment.

Why wrong: Secure Boot and vTPM are features of Generation 2 VMs in Azure; they rely on a Virtual Firmware (UEFI) architecture that Generation 1 VMs simply do not expose. You cannot "enable" these capabilities on an existing Generation 1 VM because it emulates BIOS and lacks the required device firmware. You must deploy a Generation 2 image from the start to use Trusted Launch or Confidential Compute. Therefore, selecting a Generation 1 image and trying to secure it later is an architectural mistake, not a configuration tweak.

B-series

Why wrong: B-series is a burstable, general-purpose family that uses CPU credits to sustain only a baseline load, with limited ability for continuous high performance. Even the largest B8ms has 8 vCPUs and 32 GiB RAM, giving only 4 GiB per vCPU—half the needed memory ratio. Under prolonged reporting workloads, credit exhaustion causes severe CPU throttling, making it unsuitable for memory-intensive applications that must run consistently.

D-series

Why wrong: D-series is a general-purpose family that balances vCPU and memory for many production workloads, but it is not optimized for high memory density. A D8s_v3 instance offers 8 vCPUs and 32 GiB RAM, yielding just 4 GiB per vCPU, which is below the 8 GiB-per-vCPU threshold. To match the required memory ratio, you would need to select a much larger D-series SKU, wasting compute capacity and increasing costs unnecessarily.

F-series

Why wrong: F-series is compute-optimized, prioritizing raw CPU performance over memory capacity, with a deliberately low memory-to-core ratio. The F8s_v2 has 8 vCPUs but only 16 GiB RAM, providing just 2 GiB per vCPU—far too little for a reporting application that needs at least 8 GiB per vCPU. This would force the OS to rely heavily on page files, causing disk thrashing and destroying query performance, so it is fundamentally the wrong family.

Assign the Virtual Machine Contributor built-in role at the subscription scope

Why wrong: Granting the Virtual Machine Contributor built-in role at the subscription scope applies the role to every virtual machine in the entire subscription, not just the target workload. This role allows a broad range of VM management actions, including creating and deleting VMs, attaching and detaching disks, configuring extensions, and starting/stopping any VM. While the support desk would be able to reset the password via the VMAccess extension, they would also gain far-reaching control over all VMs in the subscription, significantly increasing the security risk and violating the principle of least privilege. The correct approach scopes the permission to a single VM and includes only the minimal actions required, avoiding the over-privileged blast radius of a subscription-wide built-in role.

Assign the Contributor role at the resource group scope

Why wrong: Assigning the Contributor role at the resource group scope grants full management access to every resource in that resource group—including virtual networks, managed disks, and storage accounts—not just the VM whose password must be reset. This broad permission set violates least privilege because the support desk could inadvertently modify or delete unrelated resources, change network security rules, or even scale resources. It also allows the user to create new resources and assign permissions to others indirectly, vastly exceeding the narrowly required password reset capability. The blast radius is further enlarged if the resource group hosts multiple production workloads.

Use an Azure Policy assignment to allow the VMAccess extension

Why wrong: An Azure Policy assignment is a governance control that enforces compliance on resource configurations, not an authorization mechanism that grants users or groups permissions to perform actions. Even if a policy is configured to deploy the VMAccess extension, it only does so automatically via a managed identity during remediation; it does not grant the support desk the RBAC permissions needed to invoke the extension or run the password reset operation. The support desk still lacks the required Microsoft.Compute/virtualMachines/extensions/write action, so any attempt to reset the password would be denied by Azure RBAC. Thus, policy is completely orthogonal to operational permissions and cannot enable an identity to perform a VM action.

Deploy the VMs so Azure distributes them across fault and update domains within that set

Why wrong: Deploying the VMs so Azure distributes them across fault and update domains within that set is the precise mechanism that makes an availability set effective: when you create VMs in the set, Azure automatically assigns them to different fault domains (up to 3) and update domains (up to 20, but commonly 5) so a single hardware failure or maintenance reboot does not affect both instances. This is exactly how to configure the VMs inside the set, and it is a correct answer as it describes the required placement behavior in technical terms.

Deploy the VMs in separate availability zones

Why wrong: Deploying the VMs in separate availability zones is not the correct choice because the scenario explicitly rules out zone-based design, and the target region may not even offer Availability Zones—many regions still do not support them. Even when zones exist, they are designed for protection against datacenter-level failures, not the fault/update domain separation that an availability set provides within a single datacenter, and they would require a more complex network architecture. Thus this option fails under the constraints.

Convert the workload to a single larger VM

Why wrong: Converting the workload to a single larger VM eliminates the redundancy that is essential for high availability; if the physical host fails, reboots for patching, or experiences a hardware fault, the application becomes completely unavailable. Azure's 99.95% VM SLA only applies when two or more VMs are deployed in the same availability set, so a single instance, regardless of size, does not meet the availability requirement. This approach also sacrifices scalability and maintenance windows, making it wrong for a business-critical app.

Put the VMs in a proximity placement group

Why wrong: Putting the VMs in a proximity placement group is intended to co-locate VMs to minimize network latency between tiers, but it actively works against resilience because the group attempts to place VMs closer together—sometimes on the same rack—which increases the risk of both VMs failing during a single fault domain or update domain event. It does not provide any inherent redundancy or separation, and it does not satisfy the availability SLA requirement, so it is wrong for this scenario.

Place the workload in a single VM with a premium SSD.

Why wrong: A premium SSD delivers high-performance storage by providing consistent low latency and high IOPS on the same physical disk infrastructure, but it does not create redundancy at the compute or host level. If the node hosting the VM experiences a hardware failure or must be rebooted for patching, the VM becomes unavailable regardless of the premium disk's resilience. This option fails the requirement because there is still exactly one point of failure: the VM itself.

Use availability zones across the region.

Why wrong: Availability zones are physically separate data centers within a region, each with independent power, cooling, and networking, and they protect against a full data center outage. However, the requirement is for resilience against platform maintenance and host failures, which a single zone's availability set already covers. Choosing zones forces compute and networking re-design for zone-to-zone traffic, higher cost, and is more resilience than the business asked for — an over-provisioned solution.

Replicate the VMs to another region with Azure Site Recovery.

Why wrong: Azure Site Recovery continuously replicates the VMs and their disks to a paired secondary region and can orchestrate a failover if the source region is lost in a disaster. This is a disaster recovery (DR) strategy that introduces multi-second to multi-minute RPO and RTO, and it only exercises failover when the entire region is down. It does not prevent in-region host failures from interrupting the application — you still need an in-region HA mechanism like an availability set.

Never

Why wrong: With the Never restart policy, Azure Container Instances will not restart the container under any circumstances after it exits. This means the container runs exactly once, and once its batch process completes, it remains in a stopped state indefinitely. This behavior is ideal for a one-time batch job that should execute and then cease running without any automatic re-execution, aligning precisely with the requirement to stop after completing its work.

Always

Why wrong: Choosing the Always restart policy causes Azure Container Instances to restart the container every time it exits, regardless of whether the exit code indicates success or failure. Consequently, a batch container would never reach a stopped state; it would perpetually restart after successful completion, leading to an endless loop of execution and unnecessary resource consumption. This contradicts the requirement that the container should stop after it finishes its batch workload.

Manual

Why wrong: A Manual restart policy does not satisfy the requirement that the container should retry only when the process fails, because Manual never restarts a container regardless of exit code; it leaves the container in a terminated state after any run. This option is tempting because Manual is the default policy for Azure Container Instances and is often chosen for one-off, interactive debugging tasks where no automatic restart is desired after a deliberate stop.

Scheduled

Why wrong: Scheduled is not a valid restart policy in Azure Container Instances; the only supported policies are Always, Never, and OnFailure. Therefore, selecting Scheduled is impossible in practice, and it cannot satisfy any restart behavior requirement. Even if such a policy existed conceptually, it would suggest timer-based restarts rather than exit-code-based behavior, which does not align with the described batch scenario.

Restore the entire virtual machine from the snapshot and overwrite the current instance.

Why wrong: A snapshot is not a full VM backup workflow in this context, and restoring the whole VM is unnecessary and risky. The requirement is to recover only the missing data disk, not to replace the working operating system disk.

Convert the snapshot into a temporary storage account and copy the files back manually.

Why wrong: A snapshot is a managed disk resource, not a blob or VHD that can be 'converted' into a storage account. To access the data, you must first create a new managed disk from the snapshot and then attach that disk to a VM—either the original or a temporary one. Copying files manually from a snapshot via a storage account is unsupported and bypasses the native recovery workflow, adding unnecessary complexity and risk without actually restoring the disk to its original state.

Recreate the VM from the same marketplace image and restore only the deleted disk later.

Why wrong: Recreating the VM from a marketplace image is unnecessary because the OS disk and configuration remain intact; the only missing component is the deleted data disk. While a new disk could be restored later, the image-based approach introduces downtime, requires reinstallation of software and reconfiguration, and risks losing VM-specific settings. The correct, minimal-impact path is to create a managed disk directly from the snapshot and attach it to the existing VM, leaving the current instance untouched.

A system-assigned managed identity on each VM instance, with account-wide storage permissions.

Why wrong: A system-assigned managed identity is intrinsically tied to the lifecycle of the individual VM instance that hosts it: when that instance is reimaged, deallocated, or replaced by the scale set's rolling upgrade, the identity is deleted and recreated with a new object ID. This means any role assignment scoped to that identity (even if account-wide) becomes stale and requires re-provisioning, breaking the upload path. Additionally, granting account-wide Storage Blob Data Contributor permissions violates least privilege, as the workload only needs to write to a single container, not the entire storage account.

A shared access signature stored in the VM image and renewed annually.

Why wrong: A shared access signature (SAS) token is still a secret, even though it is scoped to a container, and storing it in the VM image means the token is copied into every captured snapshot and may be extracted by anyone with read access to the image. Annual renewal only postpones failure: if the token expires before the image is updated, the scale set instances lose upload capability, and updating the image to embed a new token forces a full reimage and rollout. This approach also contradicts the core requirement of avoiding secrets altogether, whereas a managed identity eliminates embedded credentials entirely.

The storage account access key, because it allows the most reliable upload path.

Why wrong: The storage account access key is an account-level secret that grants full administrative access to all services and data in the storage account, not just blob uploads to one container. It is explicitly disallowed by the requirement to avoid secrets, and because it is long-lived and rarely rotated, a leak or key rotation would either expose the entire account or abruptly break the scale set's uploads. Even if rotated annually, the key remains a static secret embedded in configuration, whereas a managed identity uses Azure AD-backed authentication with no secret to manage or store.

Create the VMs manually in the Azure portal each sprint and document the clicks afterward.

Why wrong: Creating VMs manually in the Azure portal each sprint introduces human inconsistency, lacks version control, and provides no auditable history of the actual configuration. Portal deployments often include default or environment-specific values inadvertently, and documenting clicks afterward does not prevent drift or recreate the environment reliably. Without a machine-readable template in source control, there is no repeatable process to guarantee the same VM SKU, network, and settings every sprint.

Export the resources after deployment and treat the export as the only authoritative source.

Why wrong: Exporting deployed resources after the fact produces an ARM template that reflects the current runtime state, including resource IDs, tags, and read-only properties, and it omits secrets like admin passwords or keys. Treating that exported output as the authoritative source means your repository no longer represents the desired configuration, making it impossible to reliably reproduce the same VMs in a new environment. Exports are useful for troubleshooting or migration, but they are not a primary design for source-driven, repeatable deployments.

Manual creation in the Azure portal.

Why wrong: Portal-based creation is an imperative, point-and-click workflow with no accompanying source artifact to review or version. Each resource is configured interactively, making the exact configuration difficult to reproduce across environments, and there is no commit history to audit for changes. This approach cannot be automated in CI/CD pipelines and is prone to configuration drift, so it does not meet the team's requirement for a repeatable, reviewable VM deployment definition.

A one-time Azure CLI command typed into Cloud Shell.

Why wrong: Running a one-off `az vm create` command in Cloud Shell creates resources in an imperative manner, but that command is ephemeral and does not exist as a versioned, reusable artifact in source control. Because Cloud Shell is a transient session, the exact command history can be lost, and there is no idempotent state management or CI/CD integration to deploy consistently across subscriptions. This fits neither the team's need for code review nor for a repeatable deployment from source control.

A resource lock on the subscription.

Why wrong: A resource lock—such as CanNotDelete or ReadOnly—is a governance control that protects existing resources from accidental deletion or modification, but it is not a deployment definition. It cannot specify the VM's size, OS image, disk configuration, network interfaces, or extensions, and it does not instruct Azure Resource Manager to create anything. Relying on a lock mistakenly conflates post-deployment protection with declarative provisioning, which is why it is incorrect for this scenario.

Navigate to subscription → Access control (IAM) → Add → Add role assignment → Select custom role (but none exist) → Assign to user → Realize custom role missing → Create custom role → Re-assign

Why wrong: This sequence is invalid because the role assignment flow cannot reference a custom role that hasn't been defined yet. The 'Add role assignment' page only lists roles that already exist and are assignable at the chosen scope, so there is no way to select the custom role on the first attempt. After realizing the role is missing, you must exit the assignment flow, create the custom role, and then revisit the assignment process — meaning the initial assignment attempts were wasted and the re-assign step is redundant overhead. Creating the role after the fact does not retroactively grant permissions; the assignment is a separate, subsequent action that must be executed again.

Create custom role at management group scope with assignable scope set to management group → Navigate to subscription → Access control (IAM) → Add role assignment → Select custom role → Assign to user

Why wrong: This is incorrect because the custom role's assignable scopes do not include the subscription, so the role cannot be assigned at the subscription scope. The role must be created at the same scope or a parent scope that includes the target scope.

Assign built-in role to user → Create custom role with similar permissions → Remove built-in assignment → Add custom role assignment to user

Why wrong: This approach is incorrect because it creates a temporary, overly permissive state for the user by assigning a built-in role before the custom role is ready, violating the principle of least privilege. The interim built-in assignment may grant permissions you never intended the user to have, and if the removal of that assignment fails or is delayed, the user retains those excessive rights. Additionally, this adds unnecessary administrative steps and introduces risk: if an error occurs between removing the built-in role and adding the custom role, the user could lose access entirely. The correct method is to define the custom role first at the appropriate scope, then assign it directly — no interim assignments are needed.

20 individual virtual machines in the same resource group.

Why wrong: This requires more manual management and does not provide group autoscaling by default.

An availability set.

Why wrong: Availability sets improve redundancy for VMs but do not provide autoscaling or fleet management.

Azure Container Instances.

Why wrong: This changes the compute model and does not fit the requirement for identical virtual machines.

Managed disk snapshots only.

Why wrong: Managed disk snapshots provide point-in-time copies of a disk, but they are not a managed backup solution. Snapshots must be scheduled and deleted manually (or via scripts), they offer no centralized retention policy, and they are crash-consistent by default, meaning they do not guarantee file-system or application consistency for applications running inside the VM. Additionally, restore from a snapshot requires manually creating a disk and attaching it to a VM, whereas Azure Backup integrates with Recovery Services vault for a single-click restore with defined retention.

Azure Site Recovery only.

Why wrong: Azure Site Recovery is intended for disaster recovery, not routine backup. It continuously replicates the VM to a secondary Azure region to meet strict RTO/RPO targets, but it does not create point-in-time backup copies or allow configurable retention periods like a vault does. Replicated data is a live, rolling copy tied to the recovery point objective, so it cannot be used to restore a VM from months ago or recover from accidental deletion—a backup service like Azure Backup is required for that.

Boot diagnostics.

Why wrong: Boot diagnostics is a troubleshooting feature that captures serial console output and screenshots of the VM during boot. It helps diagnose startup issues such as kernel panics or OS boot failures, but it does not capture any user data, application data, or even a full OS disk image. Since it only stores transient logs and screenshots, it cannot be used to restore the VM or its data; it is not a backup or disaster-recovery mechanism.

Cross-region restore

Why wrong: Cross-region restore, while a feature of Azure Backup, is meant for region-wide outages, not routine file recovery. It allows you to restore the entire VM to a paired Azure region, preserving the full VM configuration and data. This operation is heavy-weight and incurs cross-region data transfer costs; it does not offer any selective file extraction, so using it to recover one deleted file would be unnecessarily complex and disruptive.

Azure Site Recovery failover

Why wrong: Azure Site Recovery (ASR) failover is intended for disaster recovery, not file-level restore. ASR replicates entire VMs to a secondary region and, during a failover, brings the whole VM online at the target location—a process that changes the VM's identity and network configuration. It does not provide a mechanism to browse a backup point and copy out one specific file; instead, it is designed for large-scale failover scenarios, making it inappropriate for restoring a single deleted item.

Boot diagnostics

Why wrong: Boot diagnostics is a troubleshooting feature that captures serial console output and boot screenshots of an Azure VM to help diagnose startup issues. It does not access or manage backup data, nor does it provide any file-level restore capability. Its purpose is purely observational—helping you see why a VM failed to boot—so it cannot recover deleted files from a backup.

An NSG application security group.

Why wrong: Application security groups within a network security group are a way to group VM NICs logically and then reference those groups in allow/deny rules, making security rules easier to maintain across distributed application tiers. However, an ASG is merely a metadata construct for the network security layer; it does not run processes, mount the guest file system, or provide a channel for command execution. For installing software, you need an in-guest automation mechanism, which ASGs do not offer.

A route table.

Why wrong: A route table holds user-defined routes that change the next hop for subnet or NIC traffic—pointing it to a firewall, network virtual appliance, or to the internet—so it controls only Layer-3 path selection. The resource has no mechanism to execute guest OS commands; it lives in the Azure networking plane and is never surfaced inside Windows. As a result, route tables are irrelevant to installing software after VM deployment.

A blob lifecycle rule.

Why wrong: Blob lifecycle rules are Azure Storage policies that tier or delete blobs automatically based on age, last modification, or blob index tags, which is useful for cost optimization and retention. These rules are evaluated by storage service infrastructure and have no agent or connectivity into the VM's OS, so they cannot launch an installer or modify guest configuration. Consequently, they manage data files, not Windows VM workloads.

An App Service Environment only.

Why wrong: An App Service Environment (ASE) alone does not solve the privacy requirement. ASE is a fully isolated and dedicated hosting environment that you can place inside a VNet, but it is a costly infrastructure change and still exposes a public endpoint by default unless you specifically configure an internal load balancer. The question asks for a way to restrict access to the existing web app, not for a complete hosting environment overhaul.

Access restrictions based on public IP ranges only.

Why wrong: Access restrictions based on public IP ranges are insufficient because they only filter traffic at the application layer while the app continues to have a publicly addressable endpoint on the internet. Requests still travel over public networks, just from allowed IP ranges, and they rely on header validation rather than true network isolation. This approach does not remove the public exposure and does not provide the direct, private, vNet-based connectivity that a private endpoint offers.

A public load balancer in front of the web app.

Why wrong: A public load balancer in front of the web app is not only ineffective but counterproductive for this goal. It introduces a public-facing IP address and only distributes traffic, making the service even more accessible from the internet rather than less. Furthermore, App Service with a public load balancer is not a supported configuration for private access, because the load balancer would not terminate the public exposure and cannot provide a private IP from within your VNet.

A Virtual Machine Scale Set.

Why wrong: A Virtual Machine Scale Set can provide availability and even automatically scale the number of identical VMs, but it is designed for elastic, large-scale workloads that need to react to demand. For a fixed deployment of two VMs running the same application, a scale set introduces unnecessary orchestration, autoscaling rules, and load-balancing topology, and its instances are intended to be replaceable rather than individually managed. The requirement does not mention scaling or variable capacity, so an availability set is the simpler and more precise fit.

Azure Container Apps.

Why wrong: Azure Container Apps is a fully managed serverless container platform, not a virtual machine service, so it would require re-architecting the line-of-business application into a container image and changing how compute, networking, and identity are managed. The scenario explicitly calls for two virtual machines, meaning IaaS-level control and guest OS management; Container Apps abstracts away those VMs entirely and uses a different execution and scaling model. Choosing it would alter the hosting model rather than simply solving VM availability, which is why it is incorrect here.

A private endpoint.

Why wrong: A private endpoint is a networking feature that gives an Azure service a private IP address inside a virtual network, enabling secure, private connectivity to PaaS services such as Storage, SQL Database, or Key Vault. It has nothing to do with VM placement, fault tolerance, or ensuring multiple VMs are available; it exists to control network access, not compute redundancy. Deploying one would not improve the availability of the two VMs, so it is unrelated to the stated requirement.