CCNA Deploy and Manage Azure Compute Questions

The requirement is to survive a single host failure, not a datacenter outage. Availability zones protect against datacenter failures, but placing one VM in each zone would not protect against a single host failure because each zone contains multiple hosts, and the VMs could still be on the same host within a zone.

A virtual machine scale set in a single zone does not protect against a single host failure because all VMs could be on the same host; it also doesn't meet the requirement of exactly two legacy VMs with separate fault domains.

A proximity placement group ensures low network latency between VMs but does not protect against planned maintenance or single host failure, as VMs can still be placed on the same host or fault domain.

Manual creation via Azure portal is not repeatable and cannot efficiently deploy 25 identical VMs every month, nor does it inherently enforce system-assigned managed identity at scale.

Azure Policy can enforce compliance (e.g., require managed identity) but cannot deploy 25 identical VMs from source control; it is not a deployment tool.

Azure Monitor alert rules trigger actions based on metrics or logs, not for provisioning resources like VMs. They cannot deploy VMs with specific configurations like managed identities.

A Standard HDD managed OS disk persists its contents even after VM deallocation, which contradicts the requirement that disk contents do not survive deallocation. Ephemeral OS disks are designed to be temporary and are lost on deallocation.

A premium managed data disk cannot be used as an OS disk in Azure; OS disks must be managed disks attached as OS disks, not data disks. Additionally, premium disks are overkill for a development VM that is rebuilt often and does not need persistence.

A shared disk cannot be used as an OS disk; it is only for data disks and requires cluster-aware file systems, so it cannot host the VM's operating system.

A proximity placement group reduces network latency between VMs but does not distribute them across fault domains or update domains for high availability.

A private endpoint provides secure connectivity to Azure PaaS services over a private IP address, not fault or update domain distribution for VMs.

A custom script extension is used to run scripts on VMs after deployment for configuration or software installation, not to manage fault domain and update domain distribution across a group of VMs.

An availability set protects against failures within a single datacenter (rack/update domain failures), not against an entire datacenter outage within a region.

A single virtual machine with Premium SSD does not provide redundancy; if the datacenter hosting that VM fails, the VM becomes unavailable, failing the requirement to keep running during a datacenter outage.

A proximity placement group reduces network latency between VMs but does not provide redundancy across datacenters; it cannot keep the application running during a datacenter outage.

A storage account access key is a shared secret that would need to be stored on the VM, violating the requirement to avoid storing any secrets on the VM. It also does not provide a secure, identity-based method for accessing Key Vault.

A service endpoint on the VM subnet secures Azure service access to the subnet but does not provide identity or credentials for the VM to authenticate to Key Vault. The VM still needs a way to prove its identity, which a service endpoint alone cannot do.

Using a user account in Entra ID with a stored password requires the VM to store credentials, violating the requirement to avoid storing usernames, passwords, or client secrets.

An availability set protects against hardware failures within a single datacenter, not against an entire datacenter failure. The requirement is to survive a full datacenter outage, which requires availability zones.

Using a single larger VM does not provide redundancy; if the datacenter hosting that VM fails, the workload goes offline, failing to meet the requirement of surviving an entire datacenter outage.

Auto-shutdown only powers down VMs on a schedule, not during a datacenter outage, and does not provide high availability or redundancy against zone or datacenter failures.

An availability set is used to distribute VMs across fault domains and update domains for high availability, not for preserving or replicating VM images across regions.

Snapshots capture a point-in-time copy of a disk but do not support versioning, replication across regions, or shared image management. Deploying VMs directly from snapshots lacks the centralized version history and automated replication provided by Azure Compute Gallery.

An availability set protects against rack-level failures within a single datacenter, not against an entire datacenter outage. It does not provide resilience across multiple datacenters.

Proximity placement groups reduce network latency between VMs but do not protect against datacenter-level failures; they can even place VMs in the same datacenter, increasing risk.

Attaching VMs to the same Azure Load Balancer backend pool distributes traffic but does not protect against a full datacenter failure if all VMs are in the same datacenter. The requirement is for availability during a datacenter outage, which requires physical separation across zones.

The 'Always' restart policy restarts the container regardless of exit code, which is inappropriate for a one-time import job that should not restart after successful completion.

The 'OnFailure' policy restarts the container only if it exits with a non-zero exit code, but the job completes successfully (exit code 0), so it would not restart. However, the question requires that the container should not restart at all after success, making 'Never' the correct choice.

Azure Container Instances does not support a 'Manual' restart policy. The valid policies are Always, OnFailure, and Never.

Azure Container Instances does not provide built-in HTTPS, deployment slots, or autoscale. It is a simple container runtime without the PaaS features required for the web app.

Azure Virtual Machines require the team to manage OS patching and container hosts, contradicting the requirement to avoid managing OS patching or container hosts.

Azure Kubernetes Service (AKS) requires managing the container orchestration layer and does not provide built-in HTTPS, deployment slots, or autoscale without additional configuration. It also involves managing OS patching for node pools, contradicting the requirement to avoid managing container hosts.

Azure Monitor metrics provide performance counters (e.g., CPU, memory) but do not capture serial console output or boot logs, so they cannot help inspect the boot process or view the blinking cursor issue.

Network Watcher packet capture captures network traffic, not serial console output or boot process logs. It cannot help inspect the boot process or view serial console output for a VM that fails to boot.

Azure Advisor provides recommendations for best practices, not real-time boot diagnostics. It cannot inspect the boot process or view serial console output.

The Standard_D8s_v5 has 8 vCPUs and 32 GiB of RAM, which does not meet the 64 GiB RAM requirement.

The Standard_F8s_v2 has 8 vCPUs but only 16 GiB of RAM, which is far below the required 64 GiB. It is a compute-optimized VM, not memory-optimized.

The Standard_B8ms is a burstable VM series designed for workloads with low average CPU usage but occasional spikes. It does not guarantee sustained performance of 8 vCPUs and 64 GiB RAM, and its baseline CPU performance is lower than required for a reporting application needing consistent resources.

Availability sets protect against rack-level failures within a single datacenter, not against an entire datacenter outage. They do not provide cross-datacenter redundancy.

A proximity placement group reduces network latency between VMs but does not protect against datacenter failure; it may even place VMs in the same datacenter, increasing risk.

Snapshots are point-in-time copies of a disk used for backup or recovery, not for real-time high availability. They do not provide automatic failover if a datacenter goes offline.

Azure Kubernetes Service (AKS) is designed for managing containerized applications across a cluster of VMs, requiring ongoing cluster management and incurring costs even when not actively running containers. For short-lived tasks (10-15 minutes) without server management, AKS is overkill and not cost-effective.

Azure Virtual Machine requires managing an always-on VM, which contradicts the requirement to not manage servers or an always-on VM. It also incurs costs even when not in use, unlike the short-lived container needs.

Azure App Service is a fully managed platform for hosting web apps, APIs, and mobile backends, but it requires the app to be deployed as a web application, not a standalone container. It does not support running a Linux container for a short duration without an always-on app or server management.

An availability set protects against failures within a single datacenter (rack/update domain failures), not against a full datacenter outage across zones. The question requires resilience across zones, which availability sets do not provide.

Virtual machine scale sets provide scaling and load balancing, not the strongest placement resilience against a datacenter outage. They distribute VMs across fault domains within a region but do not isolate across zones, so a single zone failure can affect all VMs.

Resource locks prevent accidental deletion or modification of resources but do not provide any placement or availability resilience against datacenter outages.

An availability set with individual VMs does not provide automatic scaling based on demand; it only ensures high availability by distributing VMs across fault and update domains. It lacks the built-in autoscaling and single management boundary of a scale set.

Azure Backup is a backup service for protecting data, not a compute scaling solution. It does not provide automatic scaling or a management boundary for VM instances.

A Recovery Services vault is used for backup and disaster recovery, not for scaling or managing compute instances. It does not provide automatic scaling or a management boundary for VM instances.

Azure Container Instances lacks built-in HTTPS, deployment slots, and autoscale; it is designed for simple container workloads without these PaaS features.

Azure Virtual Machines require managing the operating system, which contradicts the requirement that the team does not want to manage the OS. Additionally, VMs do not natively provide built-in HTTPS, deployment slots, or autoscale without additional configuration.

Azure Kubernetes Service (AKS) requires managing the operating system and Kubernetes control plane, which contradicts the requirement of not managing the OS. Additionally, AKS is overkill for a simple internet-facing application from source code and does not natively provide deployment slots.

An availability set only provides high availability for VMs by distributing them across fault domains and update domains, but it does not support automatic scaling based on CPU thresholds or manage identical VM instances as a group.

Azure Load Balancer distributes traffic across existing VMs but does not automatically add or remove VM instances based on CPU thresholds. It lacks autoscaling and fault domain distribution capabilities for VM instances.

Azure App Service is a platform-as-a-service for hosting web apps, APIs, and mobile backends, but it does not provide the ability to automatically add or remove identical VM instances based on CPU thresholds or distribute instances across fault domains. It abstracts away the underlying VMs, so you cannot manage VM-level scaling or fault domain distribution.

App Service with deployment slots is designed for web apps requiring continuous availability and scaling, not for short-lived, per-request container runs that should not leave a server running. It incurs ongoing costs and management overhead unsuitable for this batch-like workload.

A virtual machine scale set (VMSS) is designed for long-running, scalable workloads that require persistent infrastructure. The workload described is short-lived (12 minutes), needs no inbound connections, and should not leave a server running afterward, making VMSS overkill and cost-inefficient compared to Azure Container Instances.

Availability sets are a feature of Azure virtual machines, not containers, and they provide high availability for VMs by distributing them across fault and update domains. They do not apply to Azure Container Instances, which are serverless and have no concept of availability sets.

An availability set protects against rack-level failures and planned maintenance within a single datacenter, not against a full datacenter outage.

A proximity placement group reduces network latency between VMs but does not protect against a full datacenter outage because all VMs in the group can be in the same datacenter.

A single-zone virtual machine scale set places all VMs in the same availability zone, which does not protect against a full datacenter outage because if that zone fails, all VMs are lost.

Single-instance deployment with backup jobs does not provide high availability against planned maintenance or host failures; backup jobs only restore data, not ensure continuous uptime.

The question states the region does not support availability zones, so option C is factually incorrect because availability zones are not available in every region.

Placing both VMs on the same dedicated host creates a single point of failure; if the host fails, both VMs go down, violating the requirement to survive a single host failure.

An availability set does not provide automatic scaling or instance addition/removal based on CPU usage; it only ensures high availability by distributing VMs across fault and update domains within a single set.

Availability zones are physically separate data centers within a region, providing high availability and disaster recovery, but they do not automatically scale VM instances based on CPU usage or distribute instances across fault domains without manual placement.

Proximity placement groups reduce network latency between VMs but do not provide autoscaling, load distribution across fault domains, or automatic instance management based on CPU usage.

A single availability set with one VM provides no redundancy; if the datacenter fails, the application goes down, and it cannot scale out to handle load spikes.

Deploying one larger VM with premium SSD does not provide high availability across datacenters or scalability for load spikes; it creates a single point of failure and cannot dynamically add/remove instances.

Azure Policy enforces compliance rules on resources but cannot execute scripts inside a VM after deployment; it only audits or applies configurations at the resource level.

Boot diagnostics captures serial console output and screenshots for troubleshooting boot failures, but it does not execute scripts or configure applications inside the VM after deployment.

An availability set is used to ensure high availability of VMs by distributing them across fault and update domains, not for running scripts after deployment.

An availability set with two fault domains protects against rack-level failures within a single datacenter, not against a full datacenter failure. The question requires physical separation across different datacenters, which only availability zones provide.

A proximity placement group reduces network latency by co-locating VMs, but it does not protect against datacenter failure because VMs can still be placed in the same datacenter or fault domain.

A single larger VM with Premium SSD does not provide protection from a datacenter failure because it is a single VM that can still be affected by a datacenter outage, regardless of its size or disk type.

The question is about restoring a missing data disk, not the OS disk or the entire VM. Recreating the VM from the marketplace image would lose all OS-level customizations and applications, and does not restore the data disk.

Converting a snapshot directly into an OS disk and replacing the VM would overwrite the operating system, not restore a missing data disk. The snapshot is of a data disk, not an OS disk, so this action would corrupt the VM's OS.

Increasing VM size does not automatically recreate missing data disks; Azure only adjusts compute and storage capacity, not individual disk attachments.

Azure Virtual Machines require managing the OS, patches, and scaling, and are not optimized for short-lived container tasks or built-in web app features like deployment slots and autoscale without additional configuration.

Azure Kubernetes Service (AKS) requires managing a cluster and is overkill for a single container running for 15 minutes with no inbound traffic. It also does not provide built-in deployment slots or autoscale for web apps without additional configuration.

Azure Batch is designed for large-scale parallel and high-performance computing jobs, not for running a single Linux container for 15 minutes per request without cluster management. It requires job and task orchestration, which adds complexity not needed here.

An availability set protects against hardware failures within a single datacenter, not against an entire datacenter outage. The question requires resilience if one datacenter becomes unavailable, which spans across datacenters, not within one.

A single virtual machine scale set instance does not provide high availability across datacenters; it is a single VM, and if that VM's datacenter fails, the app goes down.

A proximity placement group reduces network latency between VMs but does not provide datacenter-level redundancy; if one datacenter fails, all VMs in the group could be affected.

An availability set provides high availability by distributing VMs across fault and update domains, but it does not support automatic scaling based on CPU demand. It is a static grouping, not a scaling solution.

A Recovery Services vault is used for backup and disaster recovery, not for deploying or scaling virtual machines. It does not provide auto-scaling based on CPU demand.

Boot diagnostics captures serial console output and screenshots for troubleshooting VM boot failures, but it does not provide any mechanism for deploying multiple VMs or automatically scaling them based on CPU demand.

An availability set protects against failures within a single datacenter (e.g., rack or host failure), not against a full datacenter failure across availability zones.

A managed disk snapshot is a point-in-time backup of a disk, not a high-availability solution. It does not provide automatic failover or redundancy across datacenters, so it cannot keep the application available during a datacenter failure.

A proximity placement group reduces network latency between VMs but does not protect against a single datacenter failure, as it can span multiple availability zones or fault domains only within a single datacenter.

Managing 20 individual VMs requires manual configuration and lacks built-in autoscaling; it increases administrative overhead and does not meet the requirement for automatic scale-out based on CPU usage.

Azure Container Instances are designed for running containers without managing VMs, but they do not support automatic scale-out based on CPU usage natively; scaling requires additional orchestration like Azure Container Apps or Kubernetes, increasing administrative overhead.

An availability set is a logical grouping of VMs to ensure high availability during maintenance or failures, not for running scripts or automating post-provisioning tasks.

Azure Load Balancer distributes incoming network traffic across multiple VMs, but it does not execute scripts or automate software installation on VMs after provisioning.

A route table controls network traffic routing and cannot execute scripts or automate software installation on a VM.

Moving application binaries to a data disk does not increase vCPU or RAM, which are the likely bottleneck for performance. The question implies a need for more compute resources, not storage.

Redeploying the VM from a different marketplace image would not change the VM's SKU or performance characteristics; it would only replace the OS and software, not address the underlying resource constraints (vCPU/RAM).

Placing the VM in an availability set does not increase vCPU or RAM; it only provides high availability by distributing VMs across fault and update domains, which does not address the performance requirement for more compute resources.

Azure Monitor agent is for collecting telemetry data from VMs, not for running one-time commands or installing agents during provisioning. The question requires immediate command execution and automated agent installation, which are not capabilities of Azure Monitor agent.

Azure Bastion provides secure RDP/SSH connectivity to VMs without public IPs, but it does not execute one-time commands or install agents during provisioning. The question requires features for post-deployment command execution and automated provisioning tasks.

Ephemeral OS disks are temporary and local to the host VM; data is lost on VM deallocation or redeployment, so they cannot provide persistent application data storage or a rollback point.

Keeping files only on the OS disk and relying on reimaging does not provide a separate data disk for application data, so rebuilding the VM would lose those files. Reimaging restores the OS disk to its original state, deleting any user data.

Deleting and recreating the VM from the same image would lose all application data on the data disk because the data disk is not preserved; the new VM would start with a fresh OS disk and no attached data disk.

Resize changes the VM's size (e.g., vCPUs, RAM) but does not redeploy it to a new host. It cannot resolve host-level issues or move the VM to different physical hardware.

Capture creates an image of the VM, which deallocates and generalizes it, making it unusable for redeployment to a new host while keeping the existing configuration and disks.

Reapply is used to reapply the current configuration of the VM, such as extensions and settings, but it does not move the VM to a new host. It only reapplies the existing state without changing the underlying host.

The 'Always' restart policy restarts the container regardless of exit code, which would prevent the one-time import task from stopping after completion. The task should stop after success, so 'Never' is correct.

The 'OnFailure' restart policy restarts the container if it exits with a non-zero exit code, but the task is expected to complete successfully (exit code 0), so the container would not restart and would stop. However, the question requires the container to stop after completion, and 'Never' ensures it never restarts regardless of exit code, which is the correct choice for a one-time task.

Azure Container Instances does not support a 'Manual' restart policy; the valid policies are Always, OnFailure, and Never. Manual is not a recognized option.

Azure App Service requires managing a web framework and is designed for continuous web applications, not short-lived, triggered container runs. It also incurs costs for idle time, unlike the per-second billing of Container Instances.

Azure Kubernetes Service (AKS) requires managing a cluster and is overkill for a single container running for 15-20 minutes. The team wants to avoid managing servers, clusters, or a web framework, and AKS involves cluster management.

The team wants to avoid managing servers, but a virtual machine requires full OS management, patching, and scaling. It also doesn't provide the container-native, ephemeral execution model needed for short-lived tasks.

Manually creating each VM in the Azure portal is not repeatable or scalable for 20 identical VMs every sprint, and it cannot be stored in source control for versioning and automation.

Capturing a screenshot of portal settings does not provide a machine-readable, repeatable deployment definition; it lacks automation and version control, making it unsuitable for deploying 20 identical VMs every sprint.

Azure Policy is used to enforce compliance rules and audit configurations, not to deploy resources. It cannot create VMs automatically; it only evaluates or remediates existing resources.

Azure Kubernetes Service (AKS) requires managing a cluster, even if serverless, and is overkill for a 12-minute container run. The team wants no server, cluster, or VM management, which AKS does not provide.

Azure Virtual Machines require managing a server, cluster, or VM, which contradicts the requirement to not manage any infrastructure. The team wants a serverless container solution, not a VM-based one.

Azure App Service is designed for hosting web applications, APIs, and mobile backends, not for running short-lived containers on demand without managing infrastructure. It requires an App Service Plan and is not optimized for ephemeral container execution triggered by requests.

Azure Virtual Machines require managing the underlying OS and patching, which contradicts the requirement to not manage servers. They also take longer to provision and are not optimized for short-lived tasks like a 10-minute container run.

Azure App Service requires a web app or API to be deployed, not a standalone container that runs for 10 minutes and then stops. It is designed for continuous web hosting, not ephemeral batch jobs.

Azure Kubernetes Service (AKS) is a managed Kubernetes cluster, which still requires cluster management and is overkill for running a single container for 10 minutes. The team explicitly wants to avoid managing servers or a Kubernetes cluster.

Cross-region restore is used to restore a VM or its data to a paired Azure region for disaster recovery, not for restoring individual files from a backup within the same region.

Azure Site Recovery failover is designed for disaster recovery by replicating entire VMs to a secondary region, not for granular file-level restoration from backup data.

Boot diagnostics provides screenshots and serial logs for troubleshooting VM boot failures, not file-level recovery from backups.

A single virtual machine cannot automatically scale out or in based on CPU usage; it lacks the orchestration and autoscaling capabilities needed for a stateless web app that requires dynamic instance adjustment.

An availability set provides high availability for VMs within a datacenter but does not include autoscaling capabilities to automatically add or remove instances based on CPU usage.

Managed disks are storage volumes for VMs, not a compute scaling solution. They do not provide automatic instance addition or removal based on CPU usage.

ACR admin credentials are shared secrets that must be embedded in deployment, violating the requirement to avoid embedding credentials. They are not reusable across container groups without re-exposing the secret, and recreating the container group would require re-supplying the credentials.

A shared access signature (SAS) token provides time-limited access and must be regenerated if the container group is recreated, violating the requirement that the authentication method be reusable and persist across recreation.

Resizing the managed disk in Azure only increases the disk's capacity; the VM's operating system still needs to extend the partition or file system to use the new space. Simply resizing again does not address the missing step inside the VM.

Detaching the disk and attaching it to another VM does not make the extra capacity available on the original VM; the partition must be extended inside the OS.

Creating a new VM from the disk would not utilize the extra capacity on the existing resized data disk; it would create a new VM with the same disk, still requiring partition extension inside the OS.

An availability set provides high availability for VMs but does not support autoscaling; it cannot automatically add or remove instances based on CPU load, which is required by the question.

Manual cloning and removal does not meet the requirement for automated scaling based on CPU thresholds; it lacks the autoscaling and orchestration capabilities of a scale set.

Premium SSD managed disks persist data even after deallocation, which contradicts the requirement that OS disk contents do not survive deallocation. They also do not boot faster than ephemeral disks.

Standard SSD managed disks persist data even after deallocation, which contradicts the requirement that OS disk contents do not need to survive deallocation. Additionally, they are slower than ephemeral disks for boot performance.

The VM temporary disk (D: drive on Windows, /dev/sdb on Linux) is not supported as an OS disk; it is intended for temporary data and is not bootable.

Creating a new virtual machine does not restore the deleted data disk; it creates a new VM with no data from the snapshot. The correct approach is to first create a managed disk from the snapshot, then attach it to the existing VM.

An availability set is a logical grouping of VMs to provide high availability, not a data recovery mechanism. It cannot restore a deleted data disk from a snapshot.

Resizing the VM does not restore deleted data disks; it only changes the VM's compute capacity. The question requires restoring data from a snapshot, which is unrelated to VM size.

Azure Policy is used to enforce compliance rules and audit resource configurations, not to run scripts inside a VM after deployment.

Boot diagnostics captures serial console output and screenshots to troubleshoot VM boot failures, but it cannot run scripts or install software after deployment.

A proximity placement group is used to reduce network latency between Azure resources by ensuring they are physically close, not for running scripts or installing software on a VM after deployment.

Availability sets provide high availability for VMs within a single region by distributing them across fault and update domains, but they do not address the need to deploy identical VMs across two regions, preserve version history, or enable quick rollback of images.

Attaching a user-assigned managed identity to the source VM is not required for creating and deploying images via Azure Compute Gallery; it does not address version history or rollback needs.

Boot diagnostics help troubleshoot VM boot failures but do not support versioning, rollback, or multi-region deployment of identical VMs from a captured image.

Stopping a VM (az vm stop) does not release the underlying hardware resources; resizing may still fail if the target size is unavailable in the current cluster. Deallocation is required to free the VM from its host and allow resizing to any size.

Restarting the VM does not change its allocation state; the resize operation requires the VM to be in a deallocated state (stopped and de-provisioned) to change the VM size, as the new size may require different resources. A restart only reboots the VM without releasing the underlying hardware.

Generalize prepares the VM for image creation and is not used for resizing; it would require recreating the VM, which is unnecessary and disruptive for a simple resize operation.

Deleting the VM and recreating it from the OS disk does not preserve the original VM resource, disks, and NIC as a single unit; it creates a new VM with a new resource ID, potentially losing the original VM's configuration and NIC association.

Capturing the VM into a generalized image removes machine-specific configurations (like SID and hostname) and is intended for creating reusable images, not for moving a degraded VM to fresh infrastructure while keeping its disks and NIC intact.

Converting a VM to an availability set does not move it to fresh infrastructure; it only adds high availability by grouping VMs, but the VM remains on the same degraded host until redeployed or stopped/deallocated.

Azure Policy with a modify effect enforces compliance rules on existing resources (e.g., tagging) but cannot install software or run scripts during VM deployment. It does not execute post-deployment configuration tasks like IIS installation.

An availability set is used to ensure high availability by grouping VMs across fault and update domains, not for post-deployment software installation or configuration.

A private endpoint is used to securely connect to Azure services over a private IP address within a virtual network, not to install software or run scripts on a VM after deployment.

Azure Policy enforces compliance rules on existing resources, but it does not provide a readable, repeatable deployment definition stored in source control; it's for governance, not infrastructure-as-code deployment.

Runbooks are for automating operational tasks and workflows, not for defining infrastructure deployments in a declarative, repeatable manner stored in source control.

A resource lock prevents deletion or modification of resources but does not provide a readable, repeatable deployment definition stored in source control.

Boot diagnostics configuration captures serial logs and screenshots for VM troubleshooting, but it does not enable automatic scaling based on CPU utilization thresholds.

An availability set is used to distribute VMs across fault domains and update domains for high availability, not to automatically scale instances based on CPU utilization. It does not support autoscaling rules.

A custom script extension is used to run scripts on VMs after deployment, not to configure autoscaling based on CPU utilization. It cannot define scaling rules or thresholds.

An availability set protects against failures within a single datacenter (e.g., rack or update domain failures) but does not provide resilience if an entire datacenter becomes unavailable, as all VMs in the set are in the same datacenter.

Virtual Machine Scale Set provides auto-scaling and load balancing across multiple VMs, but it does not guarantee that a single VM continues running if a datacenter fails; it requires multiple instances and may not maintain the specific VM instance.

Azure managed disks can be resized without creating a new VM; you simply stop the VM (or keep it running for some disk types), update the disk size, and then extend the partition inside the OS.

Resizing a managed data disk in Azure always increases the disk size; you cannot shrink a managed disk. The option incorrectly states that resizing shrinks the disk.

VM size and disk capacity are independent; you can change disk size without altering the VM size. The VM size only affects performance limits (IOPS/throughput), not storage capacity.

The B-series is designed for workloads with low baseline CPU usage and occasional bursts, not for sustained high memory usage. The analytics engine requires consistent high memory (64 GiB) and compute (8 vCPUs), which burstable credits cannot reliably provide.

The D-series is a general-purpose VM that balances CPU and memory, but the workload requires memory optimization (large in-memory cache) and benefits more from memory than compute, making the memory-optimized E-series a better fit.

The F-series is compute-optimized for high CPU throughput, but this workload benefits more from memory than extra compute, making it unsuitable for the large in-memory cache requirement.

Availability zones protect against datacenter-level failures by distributing VMs across physically separate zones, but the question explicitly states no protection from a complete datacenter outage is required. The requirement is only to reduce downtime during planned host maintenance, which availability sets handle by placing VMs in different fault domains within the same datacenter.

Virtual Machine Scale Sets (VMSS) are designed for auto-scaling and managing multiple identical VMs, not for reducing downtime during planned host maintenance for a fixed set of two VMs. An availability set provides fault and update domain isolation for two VMs, which directly addresses the requirement.

Proximity placement groups reduce network latency between VMs but do not provide any redundancy or protection against planned host maintenance or datacenter outages. They are not designed for high availability.

The 'Always' policy restarts the container regardless of exit code, so even after a successful job completion, the container would restart, preventing it from staying stopped as required.

The 'Never' restart policy means the container will never be restarted, even if the job fails. Since the requirement is to automatically retry on failure, 'Never' does not satisfy the retry condition.

The 'Manual' restart policy is not a valid option for Azure Container Instances; the available policies are Always, Never, and OnFailure. Therefore, it cannot be selected for any restart behavior.

A managed disk snapshot captures a point-in-time copy of a single disk, but it does not support versioning, replication across subscriptions, or the structured testing and promotion workflow required for maintaining a hardened image pipeline.

A custom script extension runs scripts during VM provisioning but does not create a reusable, versioned image that can be deployed across multiple subscriptions and tested before promotion.

An availability set is a logical grouping of VMs to provide high availability during maintenance or failures, not a mechanism for deploying versioned images across multiple subscriptions or managing image lifecycle.

An availability set provides high availability for a fixed number of VMs but does not support automatic scaling based on CPU usage or schedule.

A single VM with a larger disk cannot automatically scale out or in based on CPU usage; it lacks the ability to add or remove instances dynamically, which is required for handling variable workload during the day and night.

Azure Policy is used to enforce compliance rules (e.g., tagging, allowed locations) and cannot dynamically add or remove VM instances based on CPU usage. It does not provide autoscaling capabilities.

A single large VM cannot automatically scale out or in based on demand; it only supports vertical scaling (resizing), not horizontal scaling required for handling traffic spikes.

An availability set only provides high availability for two VMs but does not automatically scale instances based on CPU usage; it lacks autoscaling capabilities required for handling traffic spikes.

Recovery Services vault backup is a disaster recovery and backup service, not designed for handling traffic spikes or automatic scaling of compute instances. It does not add or remove VMs based on CPU usage.

An availability set protects against rack-level failures within a single datacenter, not against an entire datacenter outage. Zone outages span multiple datacenters, so availability sets cannot survive a zone failure.

Keeping all instances in one zone does not survive a single datacenter outage because a zone outage would take down all instances. The load balancer cannot redistribute traffic if all backend instances are in the failed zone.

Paired regions are for cross-region disaster recovery, not for surviving a single datacenter outage within a zone-supported region. They do not provide automatic zone balancing within a region.

Placing all instances in a single availability set does not survive a datacenter outage because availability sets protect against rack-level failures within a single datacenter, not across datacenters. Manual scaling also fails to meet the requirement for automatic increase during business hours.

A single zonal VM cannot survive a datacenter outage because it is tied to one zone; snapshots do not provide automatic failover or high availability. The question requires surviving a datacenter outage, which demands redundancy across zones.

An availability set only provides high availability by distributing VMs across fault and update domains, but it does not support automatic scaling or management as a single logical group for a stateless web application.

A Recovery Services vault is used for backup and disaster recovery, not for scaling or managing virtual machines as a group.

Boot diagnostics is a feature for troubleshooting VM boot failures by capturing serial console output and screenshots, not for scaling or managing instances as a group.

Shrinking the disk would reduce capacity, not help the OS recognize the increased size. The filesystem refresh is not achieved by detaching and shrinking; the OS must extend the partition to use the new space.

Converting a data disk to a shared disk does not cause Windows to auto-detect a size increase; shared disks are for multi-VM access, not for resizing. The guest OS still requires manual partition expansion.

Redeploying a VM moves it to a new host but does not resize or refresh the disk partition inside the guest OS; the OS still sees the old partition size.

The question explicitly states 'should not use a burstable SKU', so choosing a B-series size violates that requirement. B-series VMs are burstable and not suitable for sustained memory-heavy workloads.

The workload is memory-heavy, requiring a memory-optimized VM family. Compute-optimized F-series is designed for CPU-intensive tasks, not memory-intensive ones, and does not prioritize memory performance.

The requirement specifies at least 8 vCPUs and 64 GiB of RAM, and the smallest VM size supporting managed disks may not meet these minimums, especially for memory-heavy workloads.

A single Azure VM cannot scale out to 4-12 instances; autoscale requires a scale set to add or remove VMs, not a single VM.

An availability set does not provide autoscaling; it only distributes VMs across fault and update domains for high availability. Manual resizing cannot automatically scale out based on CPU thresholds.

Azure Container Instances (ACI) does not support autoscaling based on CPU metrics for Windows containers, nor does it provide a VM-based environment for running Windows VMs; it runs containers, not VMs.

An availability set is used to ensure high availability by distributing VMs across fault and update domains, not for installing software or running scripts during deployment.

A managed disk snapshot captures the state of a disk at a point in time, but it cannot execute scripts or install software during VM deployment. The question requires running a bootstrap script and installing IIS, which is beyond the capability of a snapshot.

A public IP address enables inbound internet connectivity but does not install IIS, copy files, or run scripts during first boot. The question requires a feature that performs post-deployment configuration, which is not provided by a public IP.

An availability set is a logical grouping of VMs to protect against failures within a datacenter, but it does not provide automatic scaling based on CPU usage or schedule.

Azure Bastion provides secure RDP/SSH access to VMs without public IPs, but it does not handle auto-scaling or scheduling of VM instances based on CPU usage or time.

Proximity placement groups reduce network latency between VMs but do not provide autoscaling or scheduled instance management based on CPU usage, which is required for the stateless web application.