Deploy and Manage Azure Compute practice questions

Standard HDD

Why it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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.

Put both VMs in the same fault domain to simplify patching.

Why it fails: Placing both VMs in the same fault domain increases correlated failure risk. It defeats the purpose of resilience and would leave the app vulnerable to a single hardware failure.

Deploy the workload in availability zones anyway.

Why it fails: The scenario says the region does not support availability zones, so this option is not available. Even if it were, the question requires an answer that works in the stated region.

Use a second Azure region for the primary failover design.

Why it fails: A second region is a disaster recovery pattern, but the scenario explicitly says not to add another region. The question is about in-region resilience only.

Standard_D8s_v5

Why it fails: Has 8 vCPUs, but it provides only 32 GiB of memory.

Standard_F8s_v2

Why it fails: Provides 8 vCPUs, but the memory amount is far below 64 GiB.

Standard_B8ms

Why it fails: Is burstable and memory-limited, so it is not a steady reporting fit.

Create an App Service plan with deployment slots.

Why it fails: App Service plans host web apps and slots, not the per-request Linux container the pipeline starts, and they keep dedicated compute running, contradicting the no always-on server requirement. It is tempting because deployment slots suit staged web app releases, not ephemeral container instances.

Use a virtual machine scale set to host the container.

Why it fails: A virtual machine scale set provisions persistent VM instances, contradicting the requirement that nothing always-on remains after each 12-minute run. Scale sets fit long-lived, autoscaling workloads; Azure Container Instances suits this short-lived, inbound-free, per-request container execution instead.

Place the workload in an availability set for host protection.

Why it fails: Availability sets apply to virtual machines, not container groups, and provide host-level redundancy that a 12-minute, no-inbound build run does not need. It is tempting because availability sets genuinely protect long-running multi-VM workloads, which is the scenario where they belong.

B-series

Why it fails: 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 it fails: 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 it fails: 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.

Place the target virtual machines in an availability set.

Why it fails: Incorrect. Availability sets improve VM resilience, but they do not create reusable, versioned images for deployment.

Attach a user-assigned managed identity to the source VM.

Why it fails: Incorrect. Managed identities help authentication, but they do not prepare a generalized image or manage versions.

Enable boot diagnostics on the target virtual machines.

Why it fails: Incorrect. Boot diagnostics helps troubleshooting startup problems, but it does not support image capture or rollbacks.

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

Why it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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.

D8as_v5

Why it fails: This is a smaller general-purpose size and does not provide enough memory for the workload.

F8s_v2

Why it fails: This family emphasizes compute density but falls short of the required memory capacity.

M8ms

Why it fails: This is a much larger memory-optimized size than needed and would overspend for the scenario.

Always

Why it fails: Always restarts containers indefinitely regardless of exit code, so the group never stops after the import succeeds. It is tempting because it suits long-running services such as web front ends that must stay available, which is the scenario where this policy is the right pick.

OnFailure

Why it fails: This restarts only after failure, but the question asks for the policy that stops after a successful one-time run.

Manual

Why it fails: Manual restarts nothing automatically, so the container group does not stop after the task completes; the policy governs restart behaviour, not termination. It is tempting because it suits interactive or diagnostic containers that should run only when explicitly started, which is where this policy fits.

Never

Why it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 Microsoft Entra ID-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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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.