CCNA AZ Compute Questions

An availability set protects against failures within a single datacenter (e.g., rack or update domain failures), not against a full datacenter failure within an Azure region. The question requires protection against a single datacenter failure, which spans across datacenters; availability zones are needed for that.

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

A single VM with premium SSD does not provide protection against a datacenter failure because it is a single instance; if the datacenter hosting that VM fails, the application becomes unavailable.

Availability zones protect against datacenter-level failures, not planned host maintenance within a single datacenter. The question explicitly excludes datacenter outage requirements.

Azure Load Balancer distributes traffic across VMs but does not provide any protection against planned host maintenance reboots; it does not ensure VMs are placed on separate update domains.

Virtual machine scale sets are designed for scaling out multiple VM instances and provide high availability through distribution across fault domains and update domains, but they are not the simplest solution for just two VMs. The question specifically asks to reduce reboots during planned host maintenance for two VMs, which is best achieved by an availability set that separates VMs into different update domains.

An availability set protects against hardware failures within a single datacenter but does not provide resilience if an entire datacenter becomes unavailable, as it spans only fault domains within one datacenter.

Option C is wrong because placing both VMs in one availability zone does not protect against a datacenter failure within that zone; if the zone's datacenter fails, both VMs are affected. The requirement is to survive a single datacenter failure, which requires spreading across zones.

Azure does not automatically replicate a single VM across a region; a single VM is a single point of failure and cannot survive a datacenter outage.

An availability set protects against failures within a datacenter (e.g., rack or hardware failure) but does not protect against an entire datacenter outage, as all VMs in an availability set are in the same datacenter.

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

Managed disk snapshots are point-in-time backups of disks, not a placement or high-availability option. They do not provide continuous availability if a datacenter fails; they only enable recovery from a backup.

A network security group rule allowing RDP from the Internet only controls inbound traffic to the VM, but does not install software or run scripts during provisioning.

An availability set with two fault domains is used to ensure high availability by protecting against hardware failures within a datacenter, not for installing software or running scripts during VM provisioning.

Restoring a managed disk snapshot as the OS disk provisions a VM from a pre-configured image, but it does not execute a bootstrap script or install software during provisioning; it only replicates the state at snapshot time.

An availability set provides high availability by distributing VMs across fault and update domains, but it does not support automatic scaling based on demand.

A Recovery Services vault is used for backup and disaster recovery (Azure Backup / Site Recovery), not for automatic scaling of virtual machines.

Boot diagnostics captures serial logs and screenshots for troubleshooting VM boot failures, but it does not provide any auto-scaling capabilities to handle demand spikes or scale-in.

A managed disk snapshot is tied to a single region and cannot be replicated across multiple regions. It also does not support versioning or rollback to earlier approved versions without uploading a new VHD.

A single unmanaged VHD stored in a storage account cannot be versioned or replicated across regions, and rolling back to an earlier version would require uploading a new VHD, failing the requirement to keep approved versions and enable rollback without re-uploading.

A custom script extension installs OS settings after deployment but does not provide a hardened Windows image source, versioning, or rollback capability without uploading a new VHD.

Virtual Machine Scale Set without zones does not protect against a full datacenter failure, as it operates within a single datacenter. It also does not provide the planned maintenance and single host failure protection that an Availability Set offers for Workload B.

Proximity Placement Groups reduce network latency between VMs but do not provide resilience against datacenter failures or planned maintenance; they are not a deployment model for high availability.

A single VM with premium SSD does not provide high availability; it protects only against disk failure, not datacenter or host failure, failing both Workload A's requirement for datacenter failure resilience and Workload B's need for planned maintenance protection.

Manual portal deployment is not repeatable, reviewable, or sourced from version control, failing the requirements for automation and auditability.

A temporary virtual machine snapshot is used for backup or recovery, not for repeatable, reviewable deployments from source control. It does not support versioning or infrastructure-as-code practices.

A network security group (NSG) rule collection controls traffic filtering, not VM deployment. It cannot deploy or manage VMs, so it fails to meet the requirement for repeatable and reviewable deployment from source control.

An availability set protects against failures within a single datacenter (rack/update domain failures), not against an entire datacenter becoming unavailable. The question requires resilience across datacenters, which availability sets cannot provide.

A single VM with a premium SSD data disk does not provide high availability; it is a single point of failure. If the datacenter becomes unavailable, the VM and its data are inaccessible, failing to meet the requirement of keeping the workload running.

A proximity placement group reduces network latency between VMs but does not protect against an entire datacenter failure because it does not distribute VMs across different availability zones or fault domains.

An availability set protects against rack-level failures within a single datacenter, not against a full datacenter outage. The requirement to survive a full datacenter outage demands distribution across availability zones, which are physically separate datacenters within a region.

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

A single-zone VMSS places all VMs in the same availability zone, which cannot survive a full datacenter outage because that zone is tied to a single datacenter.

A CanNotDelete lock prevents deletion of existing resources, not creation of new ones. The failure is due to a policy denial, not a lock.

Assigning the Owner role on the resource group does not automatically bypass Azure Policy denials. Policies are enforced at the Azure Resource Manager level and override any role permissions, including Owner.

Moving a VM to another subnet does not affect policy inheritance; policies are assigned to scopes (management group, subscription, resource group) and apply to all resources within that scope regardless of subnet.

Storing the ACR admin account password in a container environment variable exposes credentials in plain text, which violates security best practices and does not meet the requirement of 'without storing registry credentials.'

A SAS token is used for granting time-limited access to Azure Storage resources, not for authenticating to Azure Container Registry. Container groups pull images using registry credentials, not SAS tokens.

Placing the registry in the same resource group as the container group does not grant any authentication permissions; the container group still needs credentials to pull a private image.

A single larger VM cannot automatically scale out/in based on demand; it only provides more resources for a single instance, not dynamic scaling across multiple instances.

An availability set provides high availability for VMs within a datacenter but does not support automatic scaling based on demand. It cannot add or remove instances automatically.

Managed disk snapshots are point-in-time backups of disks, not a scaling solution. They cannot automatically add or remove instances based on demand.

The `az deployment group create` command deploys resources immediately without previewing changes, whereas the question specifically asks to see planned changes before applying them.

The 'az group delete' command removes a resource group and its resources, not preview changes. The question asks to see planned changes before applying them, which requires the what-if operation.

The 'az vm update' command is used to modify properties of an existing virtual machine, not to preview changes before deploying a resource group with Bicep.

A snapshot captures only the OS disk at a point in time and does not support versioning, sharing across subscriptions, or creating multiple VMs with the same build easily. It lacks the image management and replication capabilities needed for standardized, version-controlled deployments.

Custom script extensions run post-deployment tasks but do not capture or version the entire VM build (OS, IIS, agent, security settings). The question requires a reusable, versioned image, which only Azure Compute Gallery provides.

The exhibit shows a container group that runs a batch job; 'Always' would cause the container to restart indefinitely even after successful completion, which is not desired for a one-time task.

The container group is designed for a single-run task (e.g., a batch job) that must not restart after completion. OnFailure would restart the container if it exits with a non-zero code, but the task is expected to succeed and should not restart even on failure.

The question asks for a restart policy for a container group, and 'UnlessStopped' is not a valid restart policy for Azure Container Instances; the valid options are Always, Never, and OnFailure.

Availability zones are for high availability and fault tolerance by distributing resources across physically separate datacenters; they do not provide any mechanism to install software or run scripts on a VM.

A route table association controls network traffic routing between subnets and does not install software or run scripts on a VM.

A user-assigned managed identity alone provides authentication to Azure resources but does not execute scripts or install software on a VM. The question requires running a post-deployment configuration script, which is beyond the capability of a managed identity.

Increasing the VM size does not address boot failures caused by a custom image issue; it only provides more resources, which won't fix a corrupted boot process or driver incompatibility.

Resetting the network interface configuration does not address a boot failure at the black screen, which is a boot process issue unrelated to networking.

An availability set is used to ensure high availability by distributing VMs across fault and update domains, not to capture a VM's configuration for reuse.

A snapshot of the OS disk captures only the disk state at a point in time, but it cannot be used directly to deploy new VMs with the same configuration; you would need to create a managed image from the snapshot first.

Increasing the VM size only changes the hardware resources (CPU/RAM) and does not capture or replicate the OS configuration, application, patches, or monitoring agent. It does not create a reusable template for future VMs.

Starting from a fresh marketplace image and manually hardening it after deployment contradicts the requirement to use an approved hardened image and automate IIS installation, as it introduces manual steps and potential configuration drift.

The question requires automated IIS installation after deployment, but this option involves manual interactive login, which is not automated and violates the 'automatically' requirement.

The requirement specifies that a zone failure is not part of the requirement, so deploying VMs in separate availability zones is unnecessary and does not address the need to protect against a single physical host failure or patching event.

Using a single larger VM with snapshots does not provide high availability; if the host fails, the VM is unavailable until restored from a snapshot, which can take significant time and may lose data. The requirement is for continuous availability during host patching or failure, not just data protection.

A public load balancer distributes traffic across VMs but does not protect against planned host updates affecting both VMs simultaneously, as it does not control the underlying host maintenance schedule.

A managed image is used to create standardized VM configurations, not to protect against planned host updates. It does not provide fault isolation across update domains.

A private endpoint provides secure connectivity to Azure PaaS services over a private IP address, but it does not protect VMs from planned host updates or provide fault tolerance across update domains.

The question requires the app to upload files (write access), but Blob Data Reader only allows read access. Also, a user-assigned managed identity persists independently of the App Service lifecycle, so deleting the App Service would not automatically remove storage access.

Shared access signatures (SAS) require a secret (the storage account key or user delegation key) to generate, and the question states the app must not store secrets in configuration. Additionally, SAS tokens do not automatically revoke when the App Service is deleted unless a stored access policy is used, which still requires secret management.

Shared key access is disabled, so storage account access keys cannot be used. Additionally, storing the key in an application setting violates the requirement to not store secrets in configuration.

Azure Monitor metric alerts monitor performance metrics (e.g., CPU, memory) and trigger notifications, but they do not provide boot-time logs or screenshots to diagnose a black screen issue during VM startup.

Network Watcher IP flow verify checks connectivity and security rules for network traffic, not boot issues or OS startup logs. It cannot inspect what happened during VM boot.

Moving a VM into an availability set does not increase its CPU or memory capacity; it only provides high availability by distributing VMs across fault domains and update domains.

Replacing the VM with a snapshot does not increase compute capacity; it creates a new VM from a snapshot, which still requires selecting a VM size. The goal is to increase CPU and memory without redeploying, and resizing the existing VM achieves that directly.

Assigning a user-assigned managed identity does not increase CPU or memory; it only provides an identity for Azure resource authentication.

An Availability Set only protects against rack-level failures within a single datacenter, not against a full datacenter outage. It also does not provide automatic scaling.

A single VM cannot survive a datacenter failure because it is a single point of failure, and it cannot scale out automatically since scaling requires multiple instances.

A proximity placement group reduces network latency between VMs but does not provide datacenter failure resilience or automatic scaling, which are the two key requirements.

Using an admin user account embeds credentials in the template or requires manual entry, which violates the requirement to avoid embedding registry credentials.

A shared access signature (SAS) is used to grant limited access to Azure resources like storage blobs, not to authenticate a container group to pull images from Azure Container Registry. The question requires pulling a private image without embedding credentials, which is achieved via managed identity and AcrPull role, not SAS.

Configuring a public network access rule that allows all Azure services does not address authentication for pulling a private image; it only controls network access, not identity-based authorization.

Premium SSD OS disks persist data across VM recreations, but the question requires the cheapest OS storage option that supports nightly reimaging. Ephemeral OS disks are free and discard OS changes on deallocation, meeting the cost and reimage pattern requirements.

The temporary resource disk is not persistent; its contents are lost when the VM is reimaged or redeployed, so build caches and artifacts would not survive nightly rebuilds.

An availability set ensures VM availability during maintenance or failures, but does not make the OS disk persistent. The OS disk is still subject to reimaging, so caches and artifacts would be lost.

An availability set ensures high availability by distributing VMs across fault and update domains, but it does not execute scripts or automate first-boot configuration.

Manually logging in later does not automate the creation of a local admin account or package installation on first boot; cloud-init is designed for that purpose.

Azure Container Instances does not provide built-in HTTPS, deployment slots, or autoscaling; it is designed for simple container workloads without these features.

Virtual machine scale sets require manual configuration of HTTPS, deployment slots, and autoscale rules, and do not support direct source code deployment with built-in HTTPS and deployment slots like App Service.

An availability set provides high availability for VMs within a datacenter but does not support built-in HTTPS, deployment slots, or autoscaling for internet-facing applications from source code.

A snapshot of the generalized OS disk does not support replication to another region or centralized version management for publishing new image versions. Azure Compute Gallery is required for multi-region replication and controlled image versioning.

A VM extension is used to configure software or agents on an existing VM, not to publish, replicate, or deploy new VM images from a controlled source.

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

A proximity placement group reduces network latency between VMs but does not provide automatic scaling based on CPU usage, which is required to handle the predictable traffic pattern described.

Manual scaling requires an administrator to manually change the instance count, which does not meet the requirement for automatic scaling based on CPU thresholds.

An availability set with three update domains is used to ensure high availability for VMs during planned maintenance, not for autoscaling based on CPU usage. It does not provide automatic scaling of instance count.

An availability set provides high availability for a fixed number of VMs, but does not support automatic scaling based on CPU usage or schedule. It cannot add or remove instances dynamically.

A Recovery Services vault is used for backup and disaster recovery, not for scaling VM instances based on CPU usage or scheduling.

Azure Container Instances does not provide built-in HTTPS, deployment slots, or autoscale; it is a serverless container platform without these web app-specific features.

Azure Virtual Machine Scale Sets require managing VMs and do not natively support built-in HTTPS or deployment slots; they also lack the platform-as-a-service simplicity for deploying from source code without server management.

Azure Bastion is a service for secure RDP/SSH access to virtual machines, not for hosting web applications. It does not support HTTPS, deployment slots, or autoscale for web apps.

A single larger virtual machine cannot scale out to meet variable demand; it only scales up (increase size), which does not automatically adjust instance count based on time or load.

An availability set with two VMs provides high availability but does not automatically scale instances based on time or load; it cannot increase or decrease instances to match business hours.

A dedicated host provides physical isolation and dedicated resources for compliance or licensing needs, but it does not offer autoscaling to adjust instances based on time-of-day demand. The question requires a solution that scales instances up during business hours and down at night, which a dedicated host cannot achieve.

Azure App Service is designed for hosting web applications and RESTful APIs that require continuous runtime and inbound HTTP traffic, not for short-lived, batch container jobs that finish in under 20 minutes and have no inbound requests.

Azure Virtual Machines require persistent servers, incurring costs even when idle, and need manual scaling or additional services for orchestration, making them unsuitable for a short-lived, serverless containerized job that runs under 20 minutes.

Azure Kubernetes Service (AKS) is overkill for a short-lived batch job that finishes in under 20 minutes, as it requires a cluster with nodes running continuously, incurring cost and management overhead. The workload does not need orchestration, scaling, or persistent servers.

cloud-init is designed for Linux VM initialization during first boot, not for Windows Server VMs, and it cannot run PowerShell scripts on Windows.

Azure Policy is used to enforce compliance rules and audit configurations across resources, not to execute scripts on a single VM after deployment.

Recovery Services vault is used for backup and disaster recovery (Azure Backup, Site Recovery), not for executing scripts on a VM after provisioning.

Azure Site Recovery is a disaster recovery service for replicating and failing over VMs, not for inspecting a VM's startup process or troubleshooting boot issues.

The VM application health extension monitors application health and enables automatic repairs, but it does not provide out-of-band access to the OS startup process or console output, which is needed to diagnose a black screen and SSH failure.

Azure Backup restore point is used for recovering VM data from backups, not for inspecting the startup process or troubleshooting boot issues without OS access.

A network interface is a virtual network adapter that provides connectivity, not a source for deploying a VM's operating system image. It cannot serve as a hardened OS image.

A resource lock prevents accidental deletion or modification of a resource, but it cannot serve as a source image for deploying a VM. The question requires a source for the VM's operating system, which a resource lock does not provide.

A public IP address is a network resource that provides internet connectivity to a VM, not an operating system image. It cannot be used as a source to deploy a VM with a specific hardened OS image.

VPN Gateway requires a VPN client on the browser machine and typically assigns public IPs to the gateway, not directly connecting to VMs without public IPs. It also does not provide browser-based connectivity.

Azure Load Balancer distributes network traffic across multiple VMs but does not provide browser-based RDP/SSH connectivity without a public IP or VPN client.

Private endpoint provides secure connectivity to Azure services over a private IP address, but it does not enable browser-based RDP/SSH connectivity without a VPN client. The question requires a service that allows browser access to VMs without public IPs, which Azure Bastion provides.

A Marketplace image is a pre-configured image from a vendor, not a custom image created from the approved server build. The question requires using the same approved server build, which must be a custom image, not a generic Marketplace image.

A single managed disk snapshot cannot be used to create a new VM with the same approved server build because it lacks the necessary OS and disk configuration metadata that a managed image provides. Snapshots are point-in-time copies of a disk, not deployable images.

A public IP address is a networking resource, not an image source. It cannot be used to create a VM from a specific server build.

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

Proximity placement groups reduce network latency by keeping VMs close together, but they do not protect against datacenter-level outages. The question requires resilience across datacenters, which proximity placement groups cannot provide.

Azure Load Balancer distributes traffic across VMs but does not protect against a datacenter outage within a region; it requires VMs in separate availability zones or regions to provide that resilience.

Azure Bastion provides secure RDP/SSH access to VMs via the browser, but it requires manual login and interactive setup, which contradicts the requirement to avoid manual intervention after provisioning.

A managed identity alone provides authentication to Azure resources but does not execute scripts or install applications. The question requires automated deployment of an application, copying a configuration file, and running a bootstrap script, which a managed identity cannot perform without an extension like Custom Script Extension.

An availability set is used for high availability by distributing VMs across fault and update domains, not for automating software installation or configuration after provisioning.

An availability set protects against rack-level failures within a single datacenter, not against an entire datacenter failure. The question requires resilience if a full datacenter fails, which availability sets cannot provide.

A proximity placement group reduces network latency between VMs but does not provide fault isolation across datacenters, so it cannot protect against an entire datacenter failure.

The question requires resilience across an entire datacenter failure and automatic scaling. A single larger VM with premium managed disks provides no redundancy—if the datacenter fails, the VM is lost—and does not support autoscaling to handle traffic spikes.

An availability set protects against failures within a single datacenter (e.g., rack or hardware failure), not against the loss of an entire datacenter. The question requires resilience across datacenters, which availability sets cannot provide.

A resource lock prevents accidental deletion or modification of resources, but does not provide high availability or redundancy across datacenters. The question requires availability even if one datacenter fails, which resource locks cannot address.

User-defined routes (UDRs) control traffic flow between subnets or to on-premises networks, but they do not provide datacenter-level redundancy. The question requires availability even if one datacenter fails, which is achieved by distributing resources across availability zones, not by custom routing.

An NSG application security group is used to group virtual machines for network security rule application, not for installing software or extensions on VMs.

A route table controls network traffic routing between subnets and networks, not software installation on VMs. It cannot deploy or manage applications like Microsoft Antimalware.

Blob lifecycle rules manage the tiering or deletion of blob data in Azure Storage, not the installation of software on virtual machines.

Boot diagnostics and serial console output are used for troubleshooting boot failures, not for installing agents or running scripts without credentials. They do not execute custom scripts or download files securely.

Attaching a read-only managed disk does not allow the VM to download a configuration file from an Azure resource without storing credentials; the disk itself is a storage resource that would require authentication to access, and it does not solve the credential storage problem.

An availability set provides high availability for VMs by distributing them across fault and update domains, but it does not execute scripts or manage credentials. It cannot run a bootstrap script or download a configuration file without storing credentials.

A temporary public IP address is a networking resource, not a VM source image. It cannot provide an operating system image for VM deployment.

A network security group (NSG) rule controls inbound/outbound traffic to a VM, not the source image used to create the VM. The question asks for a source image, not a network configuration.

An Azure Monitor alert rule is used to monitor metrics or logs and trigger actions, not to provide a source image for VM creation.

Availability zones are a high-availability feature that protects VMs from datacenter failures, not a compute component for running scripts during provisioning.

An availability set is a logical grouping of VMs to ensure high availability during platform updates and failures; it does not provide point-in-time copies of disks.

Azure Policy assignment enforces compliance rules on resources, but it does not create a point-in-time copy of a disk. It cannot be used to restore a VM's data disk to a previous state.

Virtual network peering connects two virtual networks, enabling traffic between them. It does not create a point-in-time copy of a data disk or provide any backup/restore capability for VM disks.

Redeploying the VM from a marketplace image would replace the entire OS disk with a fresh image, losing all data and customizations, and does not restore the deleted data disk.

Converting a snapshot into an OS disk and booting from it would replace the VM's operating system disk, causing significant disruption and potential data loss on the OS disk, whereas the question asks to restore a data disk with minimal impact to the OS disk.

Resizing a VM does not recover deleted disks; disks are independent resources and must be recreated from snapshots or backups.

An availability set provides high availability for VMs by distributing them across fault and update domains, but it does not automate software installation or configuration after VM creation.

Azure Policy assignments enforce compliance rules on resources, but they cannot install software or run scripts on a VM. They are used for governance, not post-deployment configuration.

A network security group rule controls inbound/outbound traffic to/from a VM, not the installation or configuration of software like IIS. It cannot run scripts or install applications.

An App Service Environment (ASE) is not required to limit access to private IPs; a private endpoint on a standard App Service can achieve this without the cost and complexity of an ASE.

Access restrictions based on public IP ranges only allow filtering by public IP addresses, not private IP addresses from a virtual network. The question requires limiting access to users connecting from the corporate virtual network over private IP addresses, which cannot be achieved with public IP ranges.

A public load balancer distributes traffic to the web app over the internet, not restricting access to private IP addresses from the corporate virtual network. It does not enforce private connectivity.

An availability set ensures high availability by distributing VMs across fault domains, but it does not capture or replicate a generalized VM image across subscriptions for controlled versioned deployments.

A managed disk snapshot captures a point-in-time copy of the OS disk, but it does not support versioning, replication across regions, or controlled publishing of updates. The question requires a solution for deploying the same build to multiple subscriptions with future version management, which Azure Compute Gallery provides.

A proximity placement group ensures VMs are physically close for low latency, but does not provide image versioning or controlled publishing across subscriptions.

A single large VM cannot automatically scale out/in based on demand; it lacks the elasticity to add or remove instances dynamically.

An availability set provides high availability by distributing VMs across fault and update domains, but it does not support automatic scaling based on demand. The question requires automatic addition/removal of instances, which availability sets cannot do.

A managed image is a static template for creating VMs, not a scaling solution. It cannot automatically add or remove instances based on demand; it only provides a consistent configuration for manual or automated VM creation.

An availability set is used for high availability by distributing VMs across fault domains, not for executing initialization tasks like creating users or installing packages.

Azure Policy is used to enforce compliance rules across resources, not to execute first-boot configuration scripts or install packages on a VM. It cannot run commands inside a VM after deployment.

A managed disk snapshot captures the disk state at a point in time but does not execute first-boot configuration tasks like creating users or installing packages; it simply clones the disk content.

A read-only resource lock prevents any modifications to the VM resource group, including the Custom Script Extension needed to install IIS and run the registration script. It does not automate post-deployment configuration.

An availability set provides high availability for VMs by distributing them across fault and update domains, but it does not execute scripts or install software after provisioning. It cannot automate IIS installation or managed identity registration.

A proximity placement group reduces network latency between VMs but does not install IIS or run scripts; it has no role in post-deployment configuration or managed identity usage.

Boot diagnostics captures serial console output and screenshots for troubleshooting boot failures, but it does not install agents or copy configuration files automatically after provisioning.

Managed disk encryption secures data at rest using Azure Disk Encryption or server-side encryption, but it does not install agents or copy configuration files during VM provisioning.

An availability set is a logical grouping of VMs to provide high availability during planned or unplanned maintenance, not for running setup steps or installing agents after provisioning.

Placing both VMs in the same fault domain defeats the purpose of fault tolerance; a single hardware fault would affect both VMs, causing application downtime. The question requires resilience to a single hardware fault, which necessitates separate fault domains.

The question states the region does not support availability zones, so deploying in availability zones is not possible.

The question explicitly states the team does not want to add a second region, so using a second Azure region for failover contradicts that requirement.

Manual portal deployment is not stored as code, lacks repeatability, and cannot be version-controlled from source control, failing the requirements of being readable, repeatable, and stored as code.

Azure Advisor provides recommendations for optimizing Azure resources, but it does not enable deploying VMs from source control as code. It is not a deployment tool.

Azure Resource Explorer is a tool for browsing and managing existing Azure resources, not for deploying infrastructure as code in a repeatable, source-controlled manner.

Deleting and recreating a VM from an image is unnecessary and disruptive; Azure allows resizing a VM after deallocation, which releases the current hardware reservation and enables selection of a different size in the same or different cluster.

Attaching a new data disk does not resolve the unavailability of the target VM size in the current cluster; resizing requires deallocation to move the VM to a different cluster where the size is available.

Creating an availability set does not affect the availability of VM sizes for resizing; it only provides high availability for VMs within the set. The issue is that the target size is not available while the VM is running, which requires deallocation first.

The 'az vm create' command is used to deploy a new virtual machine, not to preview changes from a Bicep deployment. It does not provide a what-if analysis of deployment impacts.

The command 'az monitor metrics list' retrieves metric data for Azure resources, not deployment previews. It is unrelated to Bicep or ARM template deployment validation.

The `az deployment group create --mode Complete` command applies the deployment immediately without previewing changes, and Complete mode can delete resources not in the template, which is irreversible.

The 'Always' restart policy restarts the container regardless of exit code, which contradicts the requirement that the job should exit after completing successfully and not restart automatically.

The job should exit after completing successfully and not restart. 'OnFailure' restarts the container only if it exits with a non-zero exit code (failure), but the question specifies the job completes successfully, so no restart is needed.

The 'Automatic' restart policy is not a valid option in Azure Container Instances; the valid policies are Always, Never, and OnFailure. Therefore, it cannot be configured for any container group.

B-series VMs are burstable and designed for workloads with low average CPU usage but occasional spikes, not for consistent moderate CPU usage with high memory demands. They also lack the memory-to-CPU ratio needed for 64 GiB RAM with 8 vCPUs.

D-series VMs are general-purpose and balanced, but the workload benefits most from memory capacity, and E-series offers higher memory-to-core ratios (e.g., up to 8 GiB per vCPU) compared to D-series (typically 4 GiB per vCPU), making E-series more cost-effective for in-memory analytics.

F-series VMs are compute-optimized, prioritizing high CPU performance over memory capacity. The workload requires 64 GiB RAM, and F-series offers limited memory per vCPU (e.g., F8s_v2 has 8 vCPUs but only 16 GiB RAM), far below the needed 64 GiB.

An availability set protects against planned and unplanned maintenance within a single datacenter, not against an entire datacenter failure. The question requires protection from a full datacenter outage, which availability zones provide.

A proximity placement group reduces network latency by keeping VMs physically close, but it does not protect against an entire datacenter failure because all VMs could be in the same datacenter.

A single VM with Premium SSD and automatic restart cannot survive an entire datacenter failure; if the datacenter hosting that VM goes down, the VM becomes unavailable regardless of storage or restart policies.

Azure Backup is designed for data protection and recovery, not for troubleshooting boot failures. It cannot capture screenshots or serial console output of a VM's boot process.

Just-in-Time VM access is a security feature that restricts inbound traffic to VMs, not a troubleshooting tool for boot issues. It does not provide screenshots or serial console output.

Autoscale automatically adjusts the number of VM instances based on demand, but it does not provide any diagnostic tools like screenshots or serial console output for troubleshooting boot failures.

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.

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

Boot diagnostics provides troubleshooting information for VM boot failures, but it does not support deploying multiple VMs or autoscaling based on CPU demand.