Unit 5 - Practice Quiz

A virtual machine (VM) is a software emulation of a computer system. It provides the functionality of a physical computer, running an operating system and applications, but is completely software-based and runs on a physical host machine.

IaaS provides fundamental computing resources, including servers (virtual machines), storage, and networking. The user is responsible for managing the operating system, applications, and data, while the cloud provider manages the underlying hardware.

An Availability Set is a logical grouping that ensures your VMs are spread across different fault domains (hardware racks) and update domains (groups for maintenance) to protect against localized hardware failures or planned maintenance events within a datacenter.

Availability Zones are physically separate datacenters within an Azure region. Deploying resources across multiple zones provides redundancy and protects applications from failures that might affect an entire datacenter.

An App Service Plan is essentially the server farm that hosts your web apps. It dictates the underlying compute power, memory, storage, and features available to the apps running within it.

A key feature of App Service Plans is the ability to host multiple web apps. This can be a cost-effective approach as all the apps share the allocated compute resources of that plan.

Deployment slots are live apps with their own hostnames. They allow for zero-downtime deployments by letting you deploy a new version to a staging slot, validate it, and then swap it with the production slot seamlessly.

Autoscaling is a built-in feature of App Service (in Standard tier and above) that allows you to configure rules to automatically scale out (add instances) or scale in (remove instances) to match the application's load.

ACI is a serverless container service. Its primary advantage is simplicity and speed, as it provides containers-on-demand without the need to provision, configure, or manage any server infrastructure.

ACI has a per-second billing model. You are charged for the vCPU and memory resources requested by your container group for the duration that your instances are running.

The Azure CLI uses intuitive verbs for actions. To start a VM, the command is az vm start, and you must specify the name of the VM and the resource group it belongs to.

In Azure, all resources must reside in a resource group, which is a container that holds related resources for an Azure solution. The --resource-group (or -g) parameter is essential for telling Azure where to create the new virtual machine.

App Service is a PaaS offering because it abstracts away the underlying infrastructure (like OS, patching, and servers). You bring your code and configuration, and Azure manages the platform for you.

Azure App Service has excellent integration with source control systems. Setting up a CI/CD (Continuous Integration/Continuous Deployment) pipeline from a Git repository is a modern and highly efficient way to deploy updates automatically.

A Recovery Services vault is the central Azure resource for managing backups. It holds the backup data for various services like Azure VMs and Azure Files, and it's where you configure policies for backup frequency and retention.

A recovery point, or snapshot, is the stored state of your data at the time the backup was taken. You can use this point to restore your data to how it was at that specific moment.

A backup policy is a set of rules that automates the backup process. It primarily consists of two components: the backup schedule (e.g., daily at 2:00 AM) and the retention policy (e.g., keep daily backups for 30 days).

A Virtual Hard Disk (VHD) is a file format that represents a virtual hard disk drive. It contains everything that would be on a physical hard drive, such as disk partitions, file systems, and the OS.

The 'Free' and 'Shared' tiers are intended for development and testing purposes. They run on shared infrastructure and have limitations, such as not supporting custom domains or SSL.

The Azure Command-Line Interface (CLI) is a set of commands used to create and manage Azure resources from a terminal or script, providing an alternative to the graphical Azure portal.

The E-series VMs are memory-optimized and offer a high memory-to-CPU core ratio, making them ideal for relational database servers, medium to large caches, and in-memory analytics. The F-series is for compute-intensive workloads, and the N-series is for GPU-heavy tasks. While D-series is general purpose, E-series is specifically optimized for this memory-intensive scenario, making it the most appropriate choice.

By placing each tier (web and database) into its own Availability Set, you ensure that Azure's update and fault domains are applied independently to each tier. This prevents a scenario where, for example, both of your web servers are rebooted simultaneously for planned maintenance, which could happen if all VMs were in a single Availability Set.

This approach provides performance isolation for the critical production app by placing it in its own dedicated Premium plan. The non-critical staging and development apps, which have lower traffic, can share a less expensive Basic plan to minimize costs. Placing all in one plan removes isolation, and using three separate plans would be more expensive than necessary.

The az vm stop command stops the VM but does not deallocate its compute resources from the host. This means you are still billed for the resources, but the OS is shut down and the public IP is retained. In contrast, az vm deallocate stops the VM and releases the hardware, which stops compute charges and also releases a dynamic public IP address.

The 'Never' restart policy is designed for tasks that are intended to run once and then stop, such as a batch job or a data processing script. 'Always' would cause the container to restart even after successful completion, and 'OnFailure' would only restart it if the script exited with a non-zero error code. 'Never' is the most appropriate for this one-off, scheduled task.

Deployment slots are live apps with their own hostnames. You can deploy a new version of your app to a non-production slot (e.g., 'staging'). After testing, you can swap the staging slot with the production slot. This action warms up the new version before the swap and provides instant rollback capability, which is the core of a blue-green deployment strategy.

The Deployment Center in Azure App Service is designed to set up continuous integration and continuous deployment (CI/CD). By linking it to a GitHub repository and a specific branch, you can configure it to automatically build and deploy your application whenever new code is committed, streamlining the development workflow.

Cross-Region Restore works by replicating the backup data from the primary region's Recovery Services vault to a vault in the paired secondary region. In a disaster scenario where the primary region is down, you can access this replicated data in the secondary region and use it to restore the VM there. It is a manual restore process, not an automatic failover like Azure Site Recovery.

Availability Zones are physically separate locations within an Azure region, each with independent power, cooling, and networking. Deploying VMs across multiple Availability Zones protects an application from failures that affect a single datacenter. Availability Sets only protect against hardware failures or planned maintenance within a single datacenter.

Changing the pricing tier of an App Service Plan (e.g., from S1 to P2V2) is known as 'scaling up' or 'vertical scaling'. This operation increases the resources (CPU cores, RAM, storage) available to the instance(s) in the plan. 'Scaling out' or 'horizontal scaling' refers to increasing the number of VM instances running the app within the same pricing tier.

The correct Azure CLI command to change the size of an existing virtual machine is az vm resize. It requires the resource group, the VM name, and the target size as parameters. The other commands (update, scale, modify) are either used for different purposes or are not valid az vm commands for resizing.

To deploy Azure Container Instances into a virtual network, you must first delegate a subnet within that VNet to the ACI service. This delegation grants the ACI service permissions to create and manage service-specific resources in the subnet, enabling the container group to join the VNet.

Managed Disks abstract the underlying storage accounts, simplifying management and improving reliability by integrating with features like Availability Sets. For a high-traffic, I/O-intensive database, Premium SSDs provide high-performance, low-latency disk support, making the combination of Managed Disks and Premium SSD the ideal choice over slower HDDs or the more complex Unmanaged Disks.

To map a subdomain like www.contoso.com, the standard and recommended practice is to create a CNAME (Canonical Name) record. This record maps your custom domain to the App Service's default *.azurewebsites.net address. Using a CNAME is preferable to an A record because the underlying IP address of the App Service can change, and the CNAME will always resolve correctly.

A 502 error often indicates that the application container or process failed to start correctly and bind to the port. The most direct way to diagnose this is to examine the application's own logs (stdout/stderr). The App Service Log stream provides a real-time view of these logs, which will likely contain the specific exception or configuration error preventing the app from starting.

'Scaling out' (horizontal scaling) means increasing the number of instances that run your application. This distributes the load across multiple machines. Changing the tier to P1V2 is 'scaling up' (vertical scaling). While configuring a CDN is a good practice for performance, it doesn't address the immediate need to handle more server-side processing, which scaling out does.

The az vm create command is the all-in-one command for creating a virtual machine. It intelligently creates all necessary dependent resources like storage, networking, and a public IP by default unless specified otherwise. The --image UbuntuLTS specifies the OS, and --generate-ssh-keys creates and configures SSH keys for secure access. The other options use incorrect command names or parameters.

A fault domain (FD) represents a group of VMs that share a common power source and network switch (like a server rack). 3 FDs mean VMs are spread across 3 racks to protect against hardware failure. An update domain (UD) is a group of VMs that are rebooted together during planned maintenance. 10 UDs mean VMs are spread across 10 groups, and only one group is updated at a time, ensuring availability.

While standard environment variables can pass configuration, they are visible in plain text in the Azure portal and API responses. Secure environment variables are designed specifically for sensitive information like connection strings or keys. Their values are not displayed in the container's properties, providing a more secure way to inject secrets into the container at runtime.

The App Service Authentication / Authorization feature, often called 'Easy Auth', is a platform-level feature that can secure your app with just a few clicks. By configuring Azure AD as the provider, you delegate the entire authentication flow to the platform without needing to modify your application code. This is the simplest and most direct method for this requirement.

This is a synthesis question. The Proximity Placement Group (PPG) ensures that the web and app tier VMs are placed as physically close as possible in the same datacenter, satisfying the low-latency requirement. Spreading the database tier VMs across Availability Zones (physically separate datacenters within a region) provides the highest level of resilience against datacenter-level failures, offering a 99.99% SLA for two or more instances. Combining a PPG for latency-sensitive tiers and Availability Zones for the HA-critical tier is the optimal design. An Availability Set only protects against rack-level failures within a single datacenter. Pinning a PPG to a single Zone negates the high availability of that tier. You cannot span an Availability Set across Availability Zones.

This question tests advanced JMESPath querying and knowledge of the specific data returned by az vm list. The key is knowing that the power state information is only available when the --show-details flag is used. The query then filters the array ([]) using a multi-conditional ? operator. It checks for powerState=='VM running', location=='eastus', and the nested tag value tags.Department=='Finance'. Finally, it projects ({}) the desired fields, name and privateIps, into a new structure. The other options are incorrect because they either miss the --show-details flag (making powerState unavailable), use an incorrect property name (privateIps is correct, not a long nested path), or attempt to pipe commands unnecessarily.

This question requires a deep understanding of the differences between App Service Plan tiers, especially regarding isolation and networking. The key requirement is 'Complete network isolation from other Azure tenants.' Only an App Service Environment (ASE) provides a dedicated, single-tenant deployment into a customer's VNet. The Isolated v2 plan runs on an ASEv3. A Premium v3 plan, while powerful and supporting VNet integration, still runs on multi-tenant infrastructure. An S3 plan with Hybrid Connections does not provide the required level of network isolation or scale. An ASEv2 (used by Isolated v1/Premium v2) is an older, less efficient, and more expensive technology than ASEv3 (used by Isolated v2), making the I2v2 plan the most appropriate modern choice.

This is a critical edge case in disaster recovery planning. While the vault is GRS, the ability to perform a Cross-Region Restore is an opt-in feature that must be configured on the Recovery Services Vault before any disaster. If it's not enabled, the secondary region data is only available if Microsoft declares a regional disaster and performs a failover. When CRR is enabled, you can initiate the restore yourself. However, it's crucial to understand that GRS replication is asynchronous, meaning the latest available recovery point in the secondary region will lag behind the primary, resulting in a Recovery Point Objective (RPO) that is typically a few hours, not minutes.

This question assesses the best practices for secure, integrated cloud services. The most secure and recommended approach avoids storing any secrets like connection strings or storage keys. 1) Deploying the ACI into the VNet (specifically, a delegated subnet) is necessary to bypass the service endpoint restrictions. 2) Using a system-assigned Managed Identity creates an identity for the ACI in Azure AD. 3) You can then grant this identity RBAC roles on both the Storage Account (e.g., 'Storage File Data SMB Share Contributor') and permissions within the Azure SQL Database. This allows the container to acquire tokens and authenticate to both services without handling any credentials, which is far more secure than using connection strings or storage keys, even if they are stored in Key Vault.

This question tests a nuanced but critical feature of App Service deployment slots. Settings marked as "Deployment slot setting" (also known as 'sticky' settings) do not move with the content during a swap. They are tied to the slot itself. So, the production slot always has the production connection string, and the staging slot always has the staging connection string. When you swap staging to production, the new code moves into the production slot and picks up the production connection string. When you roll back by swapping again, the old code moves back into the production slot and continues to use the same production connection string that never left the slot. This prevents the disastrous scenario of production code accidentally connecting to a staging database.

This question requires analyzing a complex workload and matching it to specialized Azure VM SKUs. The key requirements are large memory (in-memory database) and high, low-latency local disk throughput (temporary data). The Lsv3-series is specifically designed for storage-throughput-intensive workloads, featuring high-throughput, low-latency, directly-mapped local NVMe storage. This local storage is perfect for temporary data or swap files, offering superior performance over network-attached disks like Premium SSD or Ultra Disk for this use case. While Esv5-series (Memory Optimized) has a high memory-to-vCPU ratio, its reliance on network-attached storage wouldn't be as performant for the local disk requirement. M-series is overkill and optimized for massive memory sizes (like SAP HANA), making it less cost-effective. Dv5 is a general-purpose series. The Lsv3 provides the best combination of features for this specific scenario.

This is a complex troubleshooting scenario. While scaling up (A) might seem plausible, the CPU/Memory metrics suggest it's not a resource bottleneck. The key clue is the combination of 502 Bad Gateway and 'database connection timeout' logs. Azure App Services have a limit on the number of concurrent outbound connections they can make to public endpoints (like the default endpoint for Azure PostgreSQL). If the Python application is not properly managing and pooling its database connections, it can quickly open and close many connections, exhausting the available SNAT ports on the underlying App Service worker. This prevents the app from establishing new connections to the database, leading to timeouts that manifest as 502 errors to the end-user. The best solution is to implement proper connection pooling in the application and/or use VNet integration with a service endpoint/private endpoint to bypass SNAT limits.

This question tests the precise differences between Availability Sets and Availability Zones. An Availability Set protects against failures within a single datacenter by distributing VMs across different fault domains (power/network racks) and update domains (planned maintenance groups). This configuration offers a 99.95% SLA. An Availability Zone is a physically separate datacenter within the same region. Deploying VMs across two or more zones protects against the failure of an entire datacenter. This superior level of resilience is backed by a higher 99.99% SLA. Both options are protected against planned maintenance, as Azure coordinates updates across zones just as it does across update domains.

This problem requires multiple steps and cannot be solved with a single command. The boot time of a VM is not available in the standard az vm list output; it's part of the detailed instance view. Therefore, the correct logic is: 1. Get the list of VM IDs that have the AutoShutdown tag set to true using az vm list. 2. Iterate (e.g., in a Bash for loop) over this list of IDs. 3. Inside the loop, for each VM ID, call az vm get-instance-view. 4. From the instance view output, extract the boot time status timestamp. 5. Perform a date/time comparison in the script to see if the boot time is older than 24 hours. 6. If the condition is met, call az vm deallocate for that specific VM ID. az graph could be an alternative for querying but the logic of iterating and conditionally deallocating remains. run-command is inefficient and inappropriate for this management task.

This question targets the specific operational details of using the Azure Backup Archive tier. Data stored in the archive tier is offline and not immediately accessible. Before you can perform any kind of restore (full or item-level), the recovery point must be moved from the archive tier back to the operational 'vault-standard' tier. This process is called rehydration. Rehydration has two priority options (standard and high) and can take up to 15 hours for standard priority. It also has associated data retrieval costs. Only after the rehydration is complete does the recovery point become available for a standard Item-Level Restore (file recovery) operation. Direct restore from the archive tier is not possible.

This question dives into the specifics of using GPU resources in ACI. For ACI GPU workloads, you do not (and should not) package the low-level NVIDIA drivers into your container image. The ACI service provisions a GPU-enabled host VM (like an N-series VM) that already has the necessary drivers installed. Your container image only needs to include the user-mode CUDA libraries and dependencies that your application requires. ACI then makes the host drivers available to your container. GPU support in ACI is only for Linux containers, not Windows. V100 is a common and powerful GPU SKU available. For a sporadic workload, ACI's per-second billing model is highly cost-effective compared to running a dedicated GPU VM 24/7.

This question is about the 'noisy neighbor' problem within an App Service Plan. An App Service Plan is the unit of scale; all apps within a plan share the same underlying VM resources. Scaling up the plan (P3v2) would help but is not cost-effective, as you're paying for higher capacity 24/7 for a problem that occurs for 10 minutes an hour. Azure App Service does not offer per-app CPU quotas. Refactoring into an Azure Function is a good long-term solution but is not the most operationally efficient (requires code changes). The simplest, most direct, and cost-effective solution is to isolate the workload. Moving the single noisy app to its own dedicated App Service Plan (even one of the same size) completely isolates its resource consumption from the other nine apps, ensuring they are not affected. This provides workload isolation at the infrastructure level.

This is a high-level performance tuning question. For SQL Server, best practice is to separate data and log files onto different physical volumes.

1. Data Files: Need high IOPS and throughput. Premium SSD v2 is an excellent choice as it allows you to provision IOPS and throughput independently of disk size, making it potentially more cost-effective than a very large Ultra Disk for achieving 100k+ IOPS.
2. Log Files: The key requirement is latency. SQL transaction log writes are sequential and latency-sensitive. Ultra Disks are the only Azure disk offering that consistently provides sub-millisecond latency. Therefore, dedicating an Ultra Disk (even a small one) specifically for the transaction log is the optimal design for performance. Setting caching to 'ReadOnly' on a log drive is incorrect; it should be 'None' for logs. A RAID set of Premium SSDs can provide high IOPS but won't match the low latency of an Ultra Disk.

This question tests advanced App Service networking. Hybrid Connections work at the application layer (TCP) and are generally used when you can't modify the VNet, but they don't provide true network-level integration. The best solution here is VNet Integration. This feature allows the App Service to inject its outbound traffic directly into a subnet in your VNet. Once the app's traffic is in the VNet, it behaves like any other resource in that VNet. Because the VNet is already connected to the on-premises network via the S2S VPN and gateway, the VNet's routing rules will automatically know how to forward packets destined for the on-premises IP address range to the gateway, establishing the connection. This provides full network-level connectivity without exposing the App Service publicly.

The 'Swap with preview' feature is designed specifically for this scenario: to catch critical errors before they fully impact production. The process works in two phases: 1) The swap operation applies all configuration from the production slot to the staging slot and restarts it. 2) Traffic is then redirected to the warmed-up staging slot for a final validation period. If errors are detected during this preview, the correct action is to 'Cancel the swap' (or reset the swap). This immediately reverts the routing change, sending all traffic back to the original, stable production slot, thereby minimizing user impact. Completing the swap would be reckless. Scaling up doesn't address the underlying code or configuration issue. Restarting the slot might fix it, but canceling the swap is the guaranteed, immediate way to restore service.

This question tests the deepest level of Azure CLI interaction. While az vm update --set is powerful, it doesn't support all nested properties. az resource update is also an option, but az rest is the most direct and flexible tool for interacting with any ARM API endpoint, especially for PATCH operations. To update a single property, you would construct a PATCH request. The command would look something like: az rest --method PATCH --uri /subscriptions/{subId}/resourceGroups/{rg}/providers/Microsoft.Compute/virtualMachines/{vmName}?api-version=2022-03-01 --body '{"properties": {"billingProfile": {"maxPrice": -1}}}'. This method is highly specific and avoids the risk of misconfiguration that comes with fetching and re-applying an entire resource JSON.

This question requires a comprehensive understanding of Private Endpoints. Simply creating a Private Endpoint is not enough. For the backup service to work correctly, the Azure Backup agents on the VMs must be able to resolve the vault's public FQDN to the private IP address of the Private Endpoint. This requires creating and linking a Private DNS Zone for the Azure Backup service to the VNet. When the agent tries to contact myvault.backup.windowsazure.com, the Azure DNS redirects it to the private zone, which returns the private IP. Disabling public network access on the vault is the final step to enforce the security policy, ensuring the vault can only be accessed via its private endpoints. Service Endpoints are not supported for Recovery Services Vaults.

This is a complex interaction between two availability and placement features. It is indeed possible to use both Availability Zones and Proximity Placement Groups with a VMSS. The behavior is hierarchical. Azure first honors the high-availability requirement of spreading instances across the specified zones (Zone 1, Zone 2, Zone 3). Then, within each of those zones, it tries to honor the PPG by co-locating the instances in that zone as physically close as possible to other resources in the PPG that are also in that same zone. This provides a balance of high availability (zone resiliency) and low latency (PPG co-location).

This question tests knowledge of specialized VM SKUs designed for licensing-sensitive workloads. Azure offers specific VM sizes known as 'constrained vCPU' sizes. A VM like the Standard_E8-4ds_v5 has the same memory, storage, and I/O as the Standard_E8ds_v5 but exposes only half the vCPUs. In this case, it provides 4 vCPUs while running on the same hardware as an 8 vCPU instance. This effectively disables hyper-threading for the guest OS and reduces the core count for software licensing purposes, all while maintaining the high memory/storage specs of the larger parent size. This is the official and supported Azure method for handling such licensing constraints.