Practice Test #8

Incorrect. Modifying application settings (app settings/connection strings) affects runtime configuration and can be marked as slot settings, but it does not enable the deployment slots feature. If the portal doesn’t allow slot creation, the limitation is almost certainly at the App Service plan tier level, not due to missing or incorrect application settings.

Incorrect. Adding a custom domain is unrelated to deployment slots. Custom domains and TLS bindings are app-level features and do not control whether slots can be created. You can use custom domains with slots (often for testing), but you must first be on a tier that supports slots; the domain configuration is not a prerequisite to unlock slot creation.

Incorrect. Scaling out increases the number of instances (horizontal scaling) to handle more load and improve availability. It does not change the App Service plan SKU and therefore does not unlock features that are tier-dependent, such as deployment slots. If slots are unavailable, scaling out will not make the option appear.

Enabling Floating IP (Direct Server Return) changes how Azure Load Balancer handles the destination IP in certain configurations and is commonly used for scenarios like SQL Always On Availability Group listeners or specific appliance/DSR designs. It does not provide client-to-backend affinity across requests. Therefore, it won’t ensure a visitor consistently reaches the same web server for each request.

Disabling Floating IP is simply the default/typical configuration for many load-balancing rules. Like enabling it, this setting is unrelated to session affinity. It does not influence whether subsequent requests from the same client are directed to the same backend VM. It only affects specific packet handling behaviors for DSR-related scenarios.

A health probe is required so the load balancer can detect backend VM health and stop sending traffic to unhealthy instances. While critical for reliability, probes do not control how traffic is distributed among healthy instances beyond excluding failed nodes. They do not provide “sticky sessions” or guarantee that a client’s requests go to the same VM.

kubectl manages Kubernetes API objects inside the cluster (pods, deployments, services, HPA resources). AKS cluster autoscaler enablement is not configured by applying Kubernetes manifests with kubectl; it is an AKS/node pool setting controlled through Azure management plane. You might use kubectl to observe effects (pending pods, node changes), but it is not the tool to configure the autoscaler feature itself.

Set-AzVm is used to manage standalone Azure virtual machines. AKS nodes are typically part of a VM Scale Set managed by AKS, and direct VM management is not the correct approach for enabling cluster autoscaler. Autoscaler is configured at the AKS node pool level via AKS tooling, not by modifying individual VMs.

Set-AzAks is not the standard PowerShell cmdlet used to configure AKS cluster autoscaler in the way the exam expects. In practice, AKS PowerShell uses cmdlets like Set-AzAksCluster or node pool-related cmdlets (module/version dependent), but AZ-104 commonly tests portal and Azure CLI (az aks) for AKS configuration. As written, this option is not a reliable/recognized complete solution.

Incorrect. This option wrongly includes VM4. Although VM1, VM2, and VM3 are supported for Azure Backup, Windows 10 is a client OS and is not supported for Azure VM backup in the same way as supported Windows Server and Linux workloads. Auto-shutdown at 19:00 does not make VM2 ineligible, but it also does not make VM4 supported.

Incorrect. VM1 and VM2 can be backed up, but VM3 can also be protected because Ubuntu Server 18.04 LTS is a supported Linux distribution for Azure VM backup. The omission of VM3 is therefore incorrect. The only VM that should be excluded is VM4 due to its Windows 10 client OS.

Incorrect. VM1 is supported, but it is not the only eligible VM. VM2 is also supported because Windows Server 2016 is supported, and VM3 is supported because Ubuntu Server 18.04 LTS is in the supported Linux matrix. This option ignores valid supported workloads and incorrectly narrows the answer too much.