CCNA Deploy and Manage Azure Compute Questions

An availability set with manual VM resizing does not provide automatic scaling based on CPU thresholds; it only ensures high availability across fault domains, not dynamic scaling.

A single Standard D-series VM with scheduled shutdown cannot scale out to 6 instances or handle variable load; it's a fixed-size VM that only shuts down on a schedule, not based on CPU metrics.

This setup lacks autoscaling; scaling requires manual intervention or additional configuration, and unmanaged VMs do not support the automated scale-out/in rules needed for the stateless API's CPU-based scaling requirements.

A proximity placement group reduces network latency between VMs by placing them close together, but it does not protect against the failure of a single Azure host. In fact, it increases the risk of simultaneous failure because VMs are placed in close proximity, potentially on the same host.

A private endpoint provides secure connectivity to Azure PaaS services over a private IP address, not fault tolerance for VMs. It does not isolate VMs from host failures.

A custom script extension is used to run scripts on VMs after deployment, not to provide high availability or fault isolation across hosts.

Standard HDD managed disks have the highest latency among Azure disk types, which contradicts the requirement for the lowest practical latency. Additionally, they are persistent and survive deallocation, which is unnecessary for temporary VMs that can be rebuilt.

Premium SSD provides low latency but its data persists through deallocate, which contradicts the requirement that disk data does not need to survive deallocate. Ephemeral OS disk is the correct choice for lowest latency and data loss on deallocate.

Ultra Disk provides extremely low latency, but it is a managed disk that persists data through deallocate operations and is not ephemeral. The question requires the disk to not survive deallocation, so Ultra Disk does not meet that requirement.

An availability set protects against failures within a single datacenter (e.g., rack or update domain failures), not against a full datacenter outage. Since the requirement is to survive a datacenter failure, availability zones (which span separate datacenters) are needed.

Increasing VM size improves performance but does not provide datacenter-level fault tolerance; it only adds more resources within the same datacenter.

Using a custom image does not provide any datacenter-level redundancy; it only defines the OS and software configuration of the VM, not its placement or fault tolerance.

Availability zones protect against datacenter-level failures, but the question explicitly states no protection from a full datacenter outage is required. Zones also incur cross-zone latency and cost, which are unnecessary for planned host maintenance.

Shared disks allow multiple VMs to access the same managed disk simultaneously for clustered applications, but they do not provide high availability against planned host maintenance or datacenter outages.

Snapshot set is not a valid Azure placement option; it refers to a collection of disk snapshots used for backup or disaster recovery, not for VM placement during planned maintenance.

An availability set does not automatically replace unhealthy instances; it only ensures VMs are distributed across fault and update domains for high availability. The question requires automatic health-based instance management, which availability sets lack.

An Azure Dedicated Host provides dedicated physical servers for compliance or licensing, but does not offer automatic health-based instance management or horizontal scaling; it would require manual VM creation and replacement.

An availability set provides high availability by distributing VMs across fault and update domains, but does not reduce compute costs for a VM used only during business hours.

Converting the OS disk to premium SSD v2 increases cost due to higher per-GB pricing and additional IOPS charges, whereas the goal is to reduce compute cost for a VM used only during business hours.

Creating a site-to-site VPN does not reduce compute costs; it is a networking feature for connecting on-premises networks to Azure, unrelated to VM cost optimization.

A snapshot of the OS disk captures the disk state at a point in time but cannot be used directly to deploy new VMs; it must first be converted to a managed disk or image, and it does not include the data disks or the generalized sysprep state required for creating multiple VMs.

An availability set is used to ensure high availability by grouping VMs across fault and update domains, not for creating reusable VM configurations.

A larger VM size only provides more compute resources (CPU/RAM) but does not capture the pre-configured OS, patches, monitoring agent, or line-of-business software needed to replicate the approved build.

Azure Load Balancer distributes network traffic but does not provide secure browser-based RDP/SSH access to VMs without public IPs; it operates at the transport layer and cannot replace a jump server or bastion host.

VPN Gateway point-to-site requires installing a VPN client on the browser machine, which contradicts the requirement of no VPN client installation.

Application Gateway is a layer-7 load balancer that requires public IPs for frontend and does not provide secure browser-based RDP/SSH access to VMs without public IPs.

An availability set protects against rack-level failures within a single datacenter, not a full datacenter outage. The requirement to survive a full datacenter outage demands availability zones, which span separate physical locations.

Azure Backup provides disaster recovery for data and VMs, but it does not ensure high availability or prevent downtime during a datacenter outage; recovery takes time and the app would be unavailable.

Deploying both VMs without fault-domain configuration does not protect against a full datacenter outage or maintenance events, as both VMs could be placed on the same physical host or within the same datacenter, violating the requirement for high availability.

Availability zones protect against datacenter-level failures, not host-level failures. The requirement is only for host patching or failure, so an availability set (which protects against host failures within a single datacenter) is sufficient and more cost-effective.

A virtual machine scale set with autoscale only does not guarantee availability during host patching or failure; it scales out based on load, not to maintain a fixed number of VMs across fault domains. The requirement is for two VMs to stay available, not to scale dynamically.

Dedicated hosts isolate VMs from other tenants but do not protect against host patching or failure within the same host; a single dedicated host is a single point of failure, so both VMs would still be affected by a host issue.

Snapshots are not directly mountable as disks; they must first be used to create a managed disk before attaching to a VM.

Redeploying the VM and reinstalling the OS does not recover the deleted data disk; it only resets the VM's state and loses all data on the OS disk, leaving the deleted managed disk unrecovered.

Deleting the snapshot after verifying it exists would destroy the only recovery point, making data restoration impossible. The snapshot must be retained until the disk is successfully recreated and data is verified.

The error specifically states the VM agent is not ready, which is a guest OS issue, not a resource group placement issue. The Recovery Services vault can be in a different resource group than the VM and still function correctly.

Soft delete is a data protection feature that prevents accidental deletion of backup data, but it does not affect the VM agent readiness or backup job initiation. The error specifically indicates the VM agent is not responding, which is unrelated to soft delete settings.

The error specifically states the VM agent is not ready, which is a guest OS issue, not a storage capacity issue. Backup storage capacity does not affect the VM agent's readiness.

Deleting and recreating the VM would change the VM name, NIC, private IP, and attached managed disks, which must remain the same per the question constraints.

Generalizing a VM prepares it for creating reusable images, but it is unnecessary and disruptive for a simple resize operation. The question requires preserving the VM name, NIC, private IP, and disks, which are all retained by deallocating and resizing without generalization.

Taking a snapshot of the OS disk does not change the VM size; it only captures a point-in-time backup. The requirement is to resize the VM, not to back up the disk.

An availability set only protects against rack-level failures within a single datacenter, not against an entire datacenter outage. It also does not support automatic scaling.

Proximity placement groups reduce network latency by keeping VMs close together, but they do not provide fault isolation across independent zone boundaries or automatic scaling, which are required for high availability and auto-scaling across datacenters.

Dedicated hosts provide physical server isolation for compliance or licensing, but do not offer automatic scaling or distribution across independent zone boundaries, which are required for high availability and auto-scaling in this scenario.

Availability zones are used to protect applications and data from datacenter failures by distributing resources across multiple zones, not for scaling based on CPU metrics.

Azure Policy is used to enforce organizational standards and assess compliance, not to automatically scale resources based on performance metrics like CPU usage.

Update management in Azure (e.g., Azure Automation Update Management) is used to manage OS updates and patches for VMs, not to scale instances based on CPU metrics. Autoscale settings are required for scaling rules.

Boot diagnostics captures serial console output and screenshots for troubleshooting boot failures, not for running scripts or installing software after deployment.

An inbound NSG rule for WinRM would open a management port (5985/5986), violating the requirement to not open additional inbound management ports. The question explicitly prohibits this.

A proximity placement group is used to reduce network latency between VMs by ensuring they are physically close in the datacenter. It does not run scripts or install software, so it cannot deploy a custom monitoring agent.

Virtual Machine Scale Set provides autoscaling and load balancing, but the question explicitly states autoscaling is not required and only two VMs are needed. An availability set is sufficient for planned maintenance resilience.

Azure Container Apps is a serverless container service for running microservices and applications, not for deploying traditional VMs. The question explicitly requires deploying two VMs, which Container Apps does not support.

A private endpoint provides secure connectivity to Azure PaaS services over a private IP address, but it does not ensure VM availability during Azure platform maintenance. The question requires high availability for VMs, which is addressed by an availability set, not network connectivity.

Storing the service principal's secret in the VM's startup script violates the security policy forbidding passwords, certificates, or client secrets on the VM.

The custom script extension would embed the Key Vault password in plain text, violating the security policy that forbids storing passwords, certificates, or client secrets on the VM.

Interactive sign-in with an Entra ID user account is not automated and requires manual intervention, which violates the requirement for first-boot automation without storing credentials on the VM.

Azure Advisor provides recommendations for best practices in cost, security, reliability, and performance, but it does not offer real-time boot process inspection or console output for a VM that fails to boot.

Managed identity is used for authenticating to Azure resources without storing credentials, not for inspecting VM boot processes or diagnosing boot failures.

Azure Policy is used to enforce organizational standards and assess compliance, not to inspect boot processes or diagnose VM startup issues. It cannot provide boot-level logs or screenshots.

A marketplace image is a generic, pre-configured image provided by Azure or third parties, not a custom image based on an existing approved production VM. It does not include the specific custom software and configuration already present on that VM.

A snapshot captures the state of a disk at a point in time but is not directly deployable as a VM; it must first be converted to a managed disk or used to create a custom image, which adds extra steps and does not preserve the full VM configuration like network settings.

An availability set is used to distribute VMs across fault and update domains for high availability, not for backup or restore operations. It does not provide centralized backup data or protect against VM deletion.

A network security group (NSG) filters traffic to and from Azure resources but does not provide backup or restore capabilities. It cannot protect VM data or enable centralized backup restoration.

A public IP address is a networking resource that provides internet connectivity to a VM, not a backup or recovery resource. It cannot store backup data or enable VM restoration after deletion.

Network Watcher packet capture is used to diagnose network traffic issues, not to inspect the startup process of a VM. The question involves a VM that stops before the sign-in prompt, which is a boot or OS-level problem, not a network connectivity issue.

Azure Advisor provides recommendations for best practices in reliability, security, performance, and cost, but it does not offer real-time or historical access to the VM's startup logs or serial console output, which are needed to diagnose a boot failure.

Managed identity is used for authenticating to Azure services without storing credentials, not for troubleshooting boot or startup issues. It does not provide any mechanism to inspect the VM startup process.

An availability set only protects against rack-level failures and update domain reboots, not against a full datacenter outage. The question's resilience requirement demands protection against a zonal failure, which only availability zones provide.

The question focuses on resilience (high availability), not latency. A proximity placement group reduces network latency but does not protect against zonal or rack-level failures, so it fails to meet the resilience requirement.

Adding more managed disks does not provide VM resilience; it only increases storage redundancy. The question requires application VM resilience, which is about compute availability, not disk redundancy.

Stopping the VM only deallocates it; it does not force the VM to be moved to a different host. The VM may be placed back on the same problematic host when started again.

Restarting the VM does not change the underlying host; it only reboots the VM on the same host, so it would not resolve issues caused by a faulty host.

Capturing a VM creates a generalized image, which removes machine-specific configurations and managed disks, making it unsuitable for moving the VM to a different host while keeping existing managed disks and configuration.

Standard HDD managed disks have higher latency compared to SSDs or ephemeral disks, and the question specifically asks for the lowest practical disk latency for the OS.

A data disk formatted as the boot disk cannot be used as the OS disk in Azure; the OS disk must be a managed disk attached as the OS disk, not a data disk. This option does not provide the lowest latency or meet the requirement for an OS disk that is rebuilt often.

Availability zones provide high availability by protecting VMs from datacenter failures, but they do not execute PowerShell commands after deployment.

Attaching a managed identity and relying on Azure Policy does not execute PowerShell commands on the VM; it assigns permissions and enforces compliance rules, not post-deployment scripts.

Creating a snapshot before startup captures the disk state but does not execute any commands after deployment. Snapshots are for backup or recovery, not for running scripts.

Managed disk snapshots only provide crash-consistent backups for individual disks, but they lack centralized management, retention policies, and the ability to restore the entire VM configuration (including network and OS settings) in case of VM deletion or corruption.

Azure Site Recovery is designed for disaster recovery and business continuity by replicating VMs to a secondary region, not for centralized backup management with retention policies for restoring deleted or corrupted VMs.

Boot diagnostics only captures serial console output and screenshots for troubleshooting boot failures; it does not provide backup or restore capabilities for VM deletion or corruption.

An availability set provides high availability by distributing VMs across fault domains 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 based on CPU demand.

Boot diagnostics captures serial console output and screenshots for troubleshooting VM boot failures, but it does not provide automatic scaling or deployment of multiple VMs.

An availability set protects against rack-level failures within a single datacenter, not against a full datacenter failure. If one datacenter fails, all VMs in the same availability set (which are in that datacenter) become unavailable.

Larger VM sizes improve performance but do not provide redundancy or fault isolation; if a datacenter fails, all VMs in that datacenter are affected regardless of size.

Redeploying a VM does not revert the data disk to a previous state; it only migrates the VM to a new host while preserving the existing disks. The corrupted data disk would remain corrupted after redeployment.

Generalizing the VM (via Sysprep) prepares the OS for imaging, which is unnecessary and destructive for a simple data disk restore. It would reset the VM's identity and potentially break applications, while the snapshot is only for the data disk.

Replacing the snapshot with the current data disk would overwrite the snapshot, not restore the data disk. The goal is to restore the data disk from the snapshot, not replace the snapshot.

Azure Kubernetes Service (AKS) is overkill for a simple Linux container that runs for 15 minutes on demand without clustering or persistent node management. For the public web app, AKS does not provide built-in TLS, deployment slots, or autoscale out of the box; these require additional configuration.

Azure Virtual Machines require persistent node management, inbound traffic handling, and clustering, which are unnecessary for the short-lived Linux container job. For the public web app, VMs lack built-in TLS, deployment slots, and autoscale without additional configuration.

Azure Functions is event-driven and designed for short-lived executions (typically under 10 minutes), not for a 15-minute container run on demand. It also lacks native container support for arbitrary images.

Availability zones provide datacenter-level redundancy across physically separate zones, which is not required here. The question specifies that datacenter-level redundancy is not needed, and only spreading across update domains within the same region is required, which is a feature of availability sets.

Azure Backup is a data protection service for backing up VMs, not a high-availability feature. It does not distribute VMs across update domains or provide availability during planned host maintenance.

Managed disks provide storage redundancy and durability, but they do not distribute VMs across update domains to ensure availability during planned host maintenance.

The question specifies a memory-heavy workload requiring 64 GiB of RAM, and burstable VM families are designed for workloads with variable CPU usage, not consistent high memory demands.

The question specifies a memory-heavy workload with 64 GiB of RAM, and compute-optimized VMs prioritize high CPU performance over memory capacity, making them unsuitable for this requirement.

Storage-optimized VM families are designed for high disk throughput and I/O, not for large memory requirements. The question specifies a memory-heavy workload needing 64 GiB of RAM, which is not a storage concern.

Reimaging the VM would reset the OS disk to its original state, removing installed applications and custom configurations, which contradicts the requirement to keep the same OS disk and installed apps.

Moving a VM to a different availability zone does not change its CPU or memory resources; it only changes the physical location for high availability.

Creating a new storage account does not change the VM's CPU or memory resources; it only provides additional storage, which does not address the need for more compute capacity.

Availability zones place VMs in physically separate datacenters within a region, which protects against a single host failure but also introduces cross-zone latency. The requirement specifies predictable east-west latency and staying within the same region without needing full datacenter redundancy, making availability sets a better fit.

A proximity placement group reduces network latency between VMs but does not protect against host patching or failure; it can place VMs on the same host, increasing failure risk.

A single VM scale set instance does not provide high availability; it is just one VM. The requirement for two backend VMs to remain available during host patching or failure necessitates redundancy, which a single instance cannot offer.

The D8as_v5 has only 32 GiB of RAM, which is half the required 64 GiB, and it lacks a local temporary disk for cache, failing the storage requirement.

The F8s_v2 has only 8 vCPUs and 16 GiB of RAM, which is far below the required 64 GiB of RAM for the reporting application.

The M8ms is a memory-optimized VM from the M-series, which is designed for large in-memory workloads like SAP HANA. It provides 8 vCPUs and 64 GiB of RAM, but it is a specialty series that is significantly more expensive than the E-series, and the question specifies avoiding unnecessarily large specialty series. Additionally, the M8ms does not include a temporary local disk for cache, which is required by the application.

Availability zones provide datacenter-level redundancy across multiple physical locations within a region, but the question explicitly states no separate datacenter protection is needed. The requirement is only for protection against planned maintenance and a single hardware host failure, which an availability set handles within a single datacenter.

Proximity placement groups reduce network latency between VMs but do not provide high availability against planned maintenance or hardware failures. They lack fault domain and update domain isolation.

A virtual machine scale set provides auto-scaling and load balancing across multiple VMs, but it does not guarantee protection against planned maintenance or a single hardware host failure unless combined with an availability set or zones. The question specifies only two VMs and no need for scaling, making an availability set the simpler and correct choice.