Deploy and manage Azure compute resources

• Redeploy — moves the VM to a new physical host within Azure. The VM is deallocated, moved to a new host, and restarted. This resolves physical host issues and is the correct action when a maintenance notification says the current host will be affected. The VM gets a new host assignment.
• Reapply — re-applies the VM's configuration on the same host. This resolves issues with extensions, guest agent connectivity, or configuration drift — not hardware problems. It does not change the physical host.

While a VM is running, it is bound to its current physical host. Deallocating the VM releases that binding. When the VM is started again after the resize, Azure can place it on any host in the region that supports the new size — it is no longer constrained to the original host cluster. This is why deallocating before resizing is the correct first step when a size is unavailable.

To enable Azure Disk Encryption with a KEK on a running VM, use: Set-AzVMDiskEncryptionExtension. This cmdlet installs the ADE extension on the VM and configures it with the specified Key Vault and KEK. The -KeyEncryptionKeyUrl parameter specifies the KEK. This is the only correct cmdlet — not Set-AzDiskEncryptionKey (which does not exist as a standard cmdlet) and not Set-AzDiskDiskEncryptionKey.

Azure Disk Encryption can only be enabled on running (started) virtual machines. A VM that is in the Stopped (Deallocated) state cannot be encrypted because the ADE extension needs to execute within the running operating system to configure BitLocker or DM-Crypt. If a question presents a mix of running and deallocated VMs and asks which ones can be encrypted, the answer includes only the running ones.

LRS (Locally Redundant Storage) keeps 3 copies within one datacenter — it does not survive a full datacenter outage. ZRS (Zone-Redundant Storage) keeps 3 copies across 3 availability zones — it survives a datacenter outage within the region. When the requirement states "resilience against a datacenter outage," ZRS is required.

• Running VMs — consume vCPU quota. Their vCPUs count against the regional and family limits.
• Stopped (Deallocated) VMs — do not consume quota. Deallocating releases the compute allocation back to the pool. This is why "Stop (Deallocate)" reduces quota usage, while "Shut down from within the OS" (which leaves the VM in Stopped but not Deallocated) does not.
• Stopped (not deallocated) VMs — still consume quota. The VM still has compute resources reserved even though it is not actively running.

During planned maintenance, Azure reboots all VMs in one update domain at a time. To guarantee that at least M VMs out of N total remain running, you need at least enough UDs so that each UD contains at most N − M VMs.

• 2 VMs, need 1 always available: at most 1 VM per UD → need at least 2 update domains.
• 9 VMs, need 8 always available: at most 1 VM per UD → need at least 9 update domains. Choosing 10 UDs is safe (at most 1 VM per UD since 9 ÷ 10 rounds up to 1).
• 50 VMs, maximum availability: use the maximum of 20 update domains to minimise how many VMs are offline at once.

Azure distributes VMs as evenly as possible across UDs. For N VMs across D UDs, the busiest UD has ceil(N/D) VMs, and that is the maximum number offline at once. For example, 14 VMs across 10 UDs: ceil(14/10) = 2, so at most 2 VMs are offline during a maintenance window. For 14 VMs across 2 FDs: 14 ÷ 2 = 7 per FD, so an entire rack failure could take 7 VMs offline simultaneously.

To assign a VMSS or individual VM to a proximity placement group, the VMSS/VM and the PPG must be in the same Azure region. The resource group membership of the PPG or the VM is irrelevant — only the Azure region matters. When selecting a PPG for a VMSS, filter the available options by matching region: only PPGs in the same region as the VMSS are valid candidates.

1. Desired State Configuration (DSC) extension — declared as an extension in the VMSS ARM template. It references a DSC configuration script stored in Azure Blob Storage and applies that configuration to each VM instance after deployment.
2. Publish-AzVMDscConfiguration cmdlet — uploads the DSC configuration script (.ps1) to Azure Blob Storage so the DSC extension can reference it. The cmdlet and extension work together: cmdlet publishes the configuration, extension applies it.

1. Start with the initial instance count.
2. Check whether the scale-out or scale-in condition threshold was met for the entire required duration.
3. Apply the instance change (add or subtract as specified in the rule).
4. Clamp the result to the configured minimum and maximum bounds.
5. Check whether another scale event could fire within the same time window (accounting for any cooldown period).

A runbook that increases processor performance for a VM should modify the VM size property — changing the VM's SKU from a smaller size (e.g., Standard_D4s_v3) to a larger one (e.g., Standard_D8s_v3). This is done via the Azure PowerShell cmdlet Update-AzVM after setting the new size with $vm.HardwareProfile.VmSize. The runbook stops the VM, changes the size property, and restarts it.

The DC must be assigned a static IP address within the destination Azure subnet's address range. Azure reserves the first 4 addresses and the last address in each subnet (.0, .1, .2, .3, .255 for a /24), so the DC's static IP must be chosen from the remaining usable range. The DC's old on-premises IP (e.g., 192.168.2.1) cannot be used — it belongs to an entirely different address space. Dynamic (DHCP) assignment must not be used because DHCP-assigned IPs can change on VM restart, breaking AD replication and DNS.

All VMs in the Azure VNet must resolve Active Directory DNS records (domain names, SRV records for replication, Kerberos, etc.). Azure's default DNS cannot resolve AD DS names. The VNet's DNS server settings must be changed to point to the DC's new Azure static IP. Azure Private DNS zones named after the AD domain (e.g., contoso.com) are not a substitute — they are for Azure-managed resolution, not AD DS SRV records.

ASR matches subnets between source and target VNets by comparing IP address ranges (CIDR blocks). If a subnet in the target VNet has exactly the same IP range as the subnet the source VM was connected to, ASR places the test VM in that matching subnet — regardless of what either subnet is named. Subnet names like "RecoverySubnetA" or "DemoSubnet1" are irrelevant to the mapping logic.

Basic tier supports custom domain verification but not autoscaling. Standard is the cheapest tier that satisfies both requirements simultaneously. If a web app needs to verify a custom domain AND scale automatically — Standard is the minimum and correct answer for minimising cost.

• Windows plan: can host .NET Framework (ASP.NET 4.8/3.5), .NET (Core), PHP, Java, and Node.js — all Windows-compatible runtimes together.
• Linux plan: can host .NET (Core), PHP, Python, Ruby, Node.js, and Java SE — all Linux-compatible runtimes together.
• Apps requiring different OS types must use separate plans. Apps in different regions must use separate plans.

• Manual — an administrator sets the instance count explicitly. No automatic scaling occurs.
• Rules-Based — Azure Monitor rules define thresholds (CPU percentage, memory, HTTP queue length, etc.) and scaling actions. When a metric exceeds the threshold for the specified duration, a scale event fires. This is the correct method for "scale automatically when CPU exceeds 80%."
• Automatic (Azure-managed) — Azure manages the instance count without user-defined rules, based on load patterns. Available on Premium v2 and higher plans only.

After a scale event fires, the cooldown period must expire before the next scale event can fire. This prevents the system from rapidly oscillating between instance counts. To calculate the number of instances at a specific point in time:

1. Check whether the threshold condition has been met for the full required duration.
2. If yes, fire the scale event and apply min/max bounds.
3. The next scale event cannot fire until the cooldown expires.
4. Only one scale event fires per cooldown window — not multiple, even if the condition remains true.

To allow developers to deploy content to a web app using Web Deploy with their Microsoft Entra credentials, assign them the Website Contributor role. This role grants the permissions needed to deploy and manage web app content (including using Web Deploy) without providing access to Azure subscription resources, networking, or other services. It is the least-privilege role that satisfies this specific requirement.

• Must be an X.509 certificate.
• Must contain a private key — public-only certificates cannot be used for TLS binding.
• Must be current — not expired at the time of binding.
• The certificate's Common Name (CN) or Subject Alternative Name (SAN) must match the custom domain being secured.

A certificate that is expired, lacks a private key, or whose domain name does not match the web app's custom domain will not be eligible for selection during TLS binding configuration.

• Create an Azure Storage account first — this is always the prerequisite for App Service backup.
• Exclude folders using a _backup.filter file — placed in the web app's wwwroot directory, one excluded path per line. Backup policies, locks, and WebJobs cannot exclude folders from an App Service backup.
• Retention = 0 + "Keep at least one backup" = Yes means only the most recent backup is retained. Older backups are deleted immediately after the next one is created, so at any given time there is exactly one backup in storage.

Each deployment slot (production, staging, test) has its own backup configuration. A backup taken from the production slot does not include the test slot. To back up a test slot, backup must be configured separately on that slot. Cross-slot restores are permitted — a production backup can be restored to a test slot — but the backup must actually exist within its retention period.

With VNet Integration enabled, the web app can communicate with VMs, databases, and other private resources in the VNet (and in peered VNets through peering). However, internet users accessing the web app via its public URL still reach it through App Service's public frontend — VNet Integration does not affect inbound access to the web app at all.

To allow an Azure web app to connect to an on-premises SMB file share (port 445), two components are needed together: an Azure Virtual Network Gateway (which establishes the Site-to-Site VPN tunnel to the on-premises network) and VNet Integration on the web app (which enables the web app to route traffic through that VPN gateway to on-premises). The VPN gateway creates the secure tunnel; VNet Integration gives the web app access to that tunnel.

To push and pull signed images in an ACR, enable content trust on the registry. Content trust uses Docker Content Trust (DCT) to cryptographically sign and verify image layers. Enabling CMK encryption is for data-at-rest protection — not image signing. Repository-scoped tokens control access permissions — not signing. A connected registry is for offline or edge scenarios. Content trust is a Premium-tier feature; if the current tier is Standard, it must be upgraded first.

• Admin user — a built-in account with username = the registry name. Enabled via the portal. Best for quick testing or ACI deployment. Not recommended for production automated pipelines.
• Service principal + AcrPull — a service principal with the AcrPull role. Best for CI/CD pipelines and automated build systems.
• Managed identity (AKS, App Service) — recommended for Azure-hosted workloads. No credentials to manage or rotate.
• Repository-scoped token — grants access to specific repositories only. For granular access control.

When admin user is enabled on a registry named CrackCertsReg1, the admin username is CrackCertsReg1 — exactly the registry name. It is not "admin", "administrator", or "root". The password is one of two auto-generated values that can be rotated in the portal.

Enabling a dedicated data endpoint for an ACR requires configuring two separate settings in the portal:

• Networking blade — this is where the "Enable dedicated data endpoint" toggle is located. Enabling it here activates the feature and generates the dedicated FQDN.
• Properties blade — the dedicated data endpoint FQDN is displayed here for reference after it has been enabled via Networking.

Both blades must be visited: Networking to enable the feature, Properties to retrieve the endpoint FQDN. ACR Tasks, Access control (IAM), Events, and the Overview blade are not involved in this configuration.

All containers within a container group must use the same operating system. A group cannot contain a mix of Windows and Linux containers. Two containers both using Windows images — even different variants like Nano Server and Server Core — can share a group because they are both Windows. A Linux container and a Windows container cannot share a group.

Each container in a group is allocated a CPU resource request (minimum guaranteed) and optionally a CPU resource limit (maximum allowed to use). If container2 has a CPU limit that is too high, it can monopolise the group's total CPU allocation and starve container1. To ensure container1 is not negatively affected, the correct action is to decrease container2's resource limit to a value that leaves sufficient CPU available for container1. Removing limits entirely would make the problem worse.

Azure Container Instances supports mounting Azure Files shares as volumes for persistent storage. This is the only supported file-system mount type for persisting data across container restarts. Azure Blob storage, Queue storage, and Table storage cannot be mounted as file-system volumes in ACI.

• Same region required — the ACI container group and the storage account containing the Azure Files share must be in the same Azure region. A container group in East US cannot mount a share in West US.
• Both Windows and Linux ACI support Azure Files mounts — Azure Files (SMB protocol) works on both OS types within ACI.
• Configured at creation time — volume mount configuration is specified when the container group is provisioned. It cannot be added or modified on a running group.

A command override replaces the container image's default CMD/ENTRYPOINT with a custom command executed at container start. It is used to pass specific operational parameters or arguments to the container process — for example, a config file path, an operating mode flag, or specific startup options. The command override controls how the container process runs.

Environment variables are key-value pairs injected into the container's runtime environment. ACI supports two types: standard (visible in portal and API) and secure (values encrypted and never exposed in output or logs). Secure environment variables are the correct mechanism for injecting passwords, API keys, and connection strings at container startup without exposing them.

The osType property specifies the container's operating system type — either Windows or Linux. It must match the OS of the container image. Internet connectivity is controlled separately: setting ipAddress.type: Public in the ARM template allocates a public IP address, allowing internet users to reach the container. Without a public IP address allocation in the ARM template, the container is not reachable from the internet — regardless of OS type.

To create a VM with multiple data disks using a copy loop:

• Dropdown 1 (loop declaration): "copy":[ — this is the array that declares the copy loop for the dataDisks property. Not "copyIndex":[ (a function call, not an array) and not "dependsOn":[ (used for resource ordering).
• Dropdown 2 (per-iteration index): "[copyIndex — this function returns the current loop index (0, 1, 2, ...) and is used to generate unique disk names or LUN numbers within each iteration.

• Resource type for VM extensions: Microsoft.Compute/virtualMachines/extensions — this is the correct ARM resource type. The value "Extensions" alone is not a valid resource type, and Microsoft.Compute/VirtualMachines is the VM itself, not the extension.
• Settings section: contains the domain name, OU path, domain join options, restart setting, and the username. Plain text, non-sensitive values go in "Settings":{.
• ProtectedSettings section: contains sensitive values — specifically the domain join password. Passwords must go in "protectedSettings":{ so they are encrypted at rest and in transit.
• Statuses section: displays extension installation status; it is not a configuration section in an ARM template declaration.

The resourceId() function returns the fully qualified Azure resource ID for a given resource type and name. In a VM template, the dependsOn array uses resourceId() to declare that the VM resource must wait for the NIC to finish deploying before it starts:

"dependsOn": [
  "[resourceId('Microsoft.Network/networkInterfaces', 'VM1-nic')]"
]

The correct function here is resourceId() — not reference() (which retrieves runtime output values of a deployed resource) and not union() (which merges objects).

The storageProfile section of a VM resource uses imageReference to specify the OS image. The correct sub-property name is imageReference — not image, not Array, and not vhd. The vhd property is for unmanaged disk deployments (legacy); managed disk and Marketplace image deployments use imageReference.

• name: 'VNET1' — a string literal; the resource name is always "VNET1" regardless of where it is deployed or any parameters.
• location: resourceGroup().location — a dynamic function that returns the deployment resource group's Azure region at deployment time. Not a static value — it changes if the template is deployed to a different resource group in a different region.
• The name and location are different fields. The name is not derived from the location — they are independent of each other.
• Subnet validation — two subnets (10.0.0.0/24 and 10.0.1.0/24) within a VNet address space of 10.0.0.0/16 are non-overlapping and both fall within the parent range. Both provision successfully.
• Idempotency — deploying the same Bicep file more than once does not cause an error. Azure compares the desired state to the current state and applies only the differences.

By default, copyIndex() starts at 0 and increments by 1 for each iteration. A template with "name": "[concat('RG', copyIndex())]" and "count": 4 creates resources named RG0, RG1, RG2, and RG3 — not RG1 through RG4. The first resource always has index 0 unless an offset is specified: copyIndex(1) starts at 1.

When running New-AzDeployment -Location "eastus" -TemplateFile deploy.json, the -Location parameter specifies where the deployment operation record is stored in Azure (the deployment metadata). It does NOT determine the location of resource groups or resources created by the template — those are specified within the template itself (e.g., "location": "westus"). If the template hardcodes "location": "westus", the resource groups will be in West US regardless of the cmdlet's -Location parameter.