Select Two (Multi-Select) Questions

Recreate the virtual machines before the policy can evaluate them.

Why wrong: There is no need to recreate or redeploy the virtual machines because Azure Policy's Modify effect, combined with a remediation task, is designed to update existing resources in place without downtime. Recreating a VM may also fail to add the desired tag unless your deployment template explicitly includes the tag, and the new VM would still be evaluated from scratch. Policy evaluation is continuous and covers all resources, regardless of whether they were created before or after the assignment, so recreation is an unnecessary and ineffective workaround.

Change the effect from Modify to Audit to trigger the tag operation.

Why wrong: Changing the effect to Audit is logically incorrect because Audit does not perform any write operation—it only compares the resource's current tags against the policy rule and generates a compliance result. If you switch from Modify to Audit, Azure Policy will report the resources as non-compliant but will never attempt to add the costcenter tag. This would solve the original problem (applying the tag) by removing the mechanism that could apply it, making the situation worse.

Use an ephemeral OS disk for the application files

Why wrong: An ephemeral OS disk is stored on the VM's local temp drive (SSD or NVMe) and is not backed by Azure Storage. Its contents are lost when the VM is stopped/deallocated, redeployed, or rebooted for maintenance on some instances, and it cannot hold durable application data. Using it for application files means critical state may vanish without warning, leading to application failures or data loss. Ephemeral disks are intended only for temporary caching or workloads that tolerate recreating data from an external source.

Keep the files only on the OS disk and rely on reimaging

Why wrong: Storing application data on the OS disk couples your data lifecycle to the VM image and the OS disk's health. Reimaging replaces the entire OS disk with a fresh copy from the image, erasing any files that were added or modified—including your application data—unless you had already captured them in a custom image. Additionally, if the OS disk experiences corruption or must be deleted to resize the VM, the data goes with it. This approach eliminates the isolation that Azure's data disk architecture exists to provide.

Delete and recreate the VM from the same image

Why wrong: Deleting a VM and recreating it from the same image discards the current OS disk and any attached data disks, unless you explicitly detach and preserve them beforehand. The image represents only the captured or marketplace configuration at the time it was created, so any subsequent writes, user data, or runtime state are lost forever. Merely recreating the VM does not restore the pre-change state of the data disk; it resets to the image's baseline. Without a separate backup or snapshot, this action amplifies data loss instead of protecting against it.

The initiative must be copied to every resource group in the new subscription before it takes effect.

Why wrong: Because the assignment is at the corp management group, it is automatically inherited by the new subscription and every resource group inside it; there is no need to copy or recreate the initiative at a lower scope. Azure Policy inheritance means that any resource group or resource in the subscription is already covered by the same assignment. Copying the initiative to each resource group would cause duplicate assignments and is unnecessary, not required.

The initiative changes RBAC so users lose read access to the subscription.

Why wrong: Azure Policy works through effects such as audit, deny, append, or deployIfNotExists to evaluate and enforce resource configurations; it never modifies Azure RBAC role assignments or permissions. Resource access (read, write, delete) is controlled by role assignments, which are unaffected by Policy. The only way a policy can appear to affect access is indirectly by denying creation of a role assignment or resource, but it does not revoke existing read access for users.

Compliance results are only visible in Activity Log, not in Azure Policy.

Why wrong: The Azure Portal has a dedicated Policy blade with a Compliance dashboard that lists per-scope compliance, per-definition results, and per-resource status; returning to the Activity Log is unnecessary and misleading. Activity Log records control-plane events (like creating or deleting resources) and does not persist the ongoing policy compliance state. Therefore, asserting that compliance results are only visible in Activity Log is incorrect because Azure Policy's own reporting surfaces are the primary and authoritative view.

Boot diagnostics

Why wrong: Boot diagnostics is a telemetry and troubleshooting feature that captures serial console output and screenshots to help diagnose why a VM failed to boot. It does not have any capacity to execute scripts or modify the virtual machine's configuration. While it uses the VM Agent to collect data, it is purely observational and cannot run a provisioning script.

Availability zone

Why wrong: An availability zone is a physically separate location within an Azure region that provides resiliency by isolating a VM from datacenter outages. Choosing a zone affects the VM's placement and availability, but it has no bearing on running initialization scripts or any post-deployment configuration logic. It is an infrastructure resilience setting, not a provisioning or scripting mechanism.

Ephemeral OS disk

Why wrong: An ephemeral OS disk places the virtual hard disk on the local node storage instead of Azure Storage, causing the disk to be deleted when the VM is deallocated. This affects persistence and IO performance but does not include any functionality to run scripts or automate setup. It is a storage deployment choice, unrelated to executing a bootstrap script during provisioning.

Azure Virtual Machines

Why wrong: An Azure Virtual Machine is the wrong choice because it would require you to deploy and manage a full Linux guest OS, apply security updates, and install a container runtime like Docker before running your job. Even if you automate the process, the VM remains provisioned and incurring costs unless you carefully shut it down after 15 minutes. This adds unnecessary administrative and operational burden compared with a managed container service.

Azure Kubernetes Service

Why wrong: Azure Kubernetes Service is overkill because it introduces an entire orchestration plane—cluster nodes, pods, load balancers, and control plane management—that you would need to configure for a single container that runs for only 15 minutes. The cluster has a baseline cost and operational overhead even when idle, and its auto-scaling and rolling-update features are not needed for an isolated short-lived job. For ephemeral workloads, a simpler service like ACI avoids this complexity.

Azure Batch

Why wrong: Azure Batch is not suitable because it is designed for large-scale parallel and high-performance computing jobs across many nodes, not for launching a single container. It requires you to create a Batch account, a pool of compute nodes, and a job with tasks, and the pool stays alive until you delete it. The orchestration and pool-management overhead far exceed the needs of a brief container run.

Install the Microsoft Monitoring Agent (MMA) on all servers and connect to a Log Analytics workspace.

Why wrong: The Microsoft Monitoring Agent (MMA) is the legacy Log Analytics agent that is being deprecated in August 2024 and lacks support for DCR-based configuration. It requires defining data sources at the workspace level and applies the same collection settings to all connected machines, making it inflexible for heterogeneous hybrid infrastructures. Choosing MMA over AMA would prevent you from using modern features like event transformation and per-DCR targeting, so it is not the correct deployment path.

Enable Network Watcher to monitor network traffic between on-premises and Azure.

Why wrong: Network Watcher provides network-level diagnostic tools such as traffic analytics, connection monitor, and VPN diagnostics, but it does not collect OS-level performance counters or application/event logs from servers. It operates within the Azure network control plane, so it cannot monitor on-premises servers unless they are behind a virtual network gateway, and even then it does not expose CPU/memory metrics. This makes it irrelevant to the requirement of gathering server telemetry from both Azure VMs and on-premises machines.

Create a VM Insights solution in the Azure portal to automatically collect data from all Azure VMs.

Why wrong: VM Insights is a monitoring solution designed specifically for Azure VMs (and Arc-enabled servers), but it is not a one-click "solution" that automatically onboards all VMs; you must explicitly enable it per machine or assign an Azure Policy to deploy it at scale. More importantly, it does not natively cover on-premises servers that are not connected through Azure Arc, leaving gaps in a hybrid infrastructure. Its data collection is also driven by predefined DCRs and may not be sufficient for custom performance counters and event logs, so it cannot replace a proper AMA + DCR deployment.

Configure a virtual network peering to connect the frontend and database subnets.

Why wrong: Virtual network peering is the wrong tool here because peering connects two separate virtual networks, not subnets within the same VNet. Subnets in a single VNet already have implicit connectivity and do not require any peering relationship; attempting to peer subnets is conceptually invalid and not supported in Azure. If the goal were to connect separate VNets, peering would be relevant, but for tier separation within one VNet it is unnecessary and misleading.

Use Azure Firewall to inspect traffic between the frontend and application tiers.

Why wrong: Using Azure Firewall to inspect traffic between the frontend and application tiers is not the correct answer for this design because Azure Firewall is a managed, layer-3/7 service intended for centralized inspection across VNets or at the perimeter, not for simple intra-VNet subnet-to-subnet filtering. For east-west traffic between subnets inside the same VNet, network security groups are typically sufficient and more cost-effective. Deploying a firewall here would add complexity and require user-defined routes to force traffic, which is unnecessary for a three-tier application.

Route traffic from the application tier to the database tier using a user-defined route (UDR) pointing to the Azure Firewall.

Why wrong: Routing application-to-database traffic through a UDR that points to Azure Firewall is wrong in this scenario because it introduces unnecessary chaining and cost; the database subnet should be protected by NSGs that only permit the application tier, not by forcing all traffic through a stateful firewall. A UDR is useful for forced tunneling or when you need an NVA/appliance, but Azure's default system routes already provide connectivity between subnets within the VNet. Also, if the UDR's next hop is a firewall, the firewall must have SNAT and high availability considerations, complicating a simple architecture.

Configure 'Password protection' with a custom banned password list.

Why wrong: A custom banned password list is a Password Protection feature that blocks weak or compromised passphrases during password set and reset operations. It does not create any user-facing password reset workflow or allow users to independently initiate a reset. It is compatible with SSPR, but it is an additive security filter, not the mechanism that permits self-service password reset.

Enable 'Combined registration' for security info to simplify MFA and SSPR registration.

Why wrong: Combined registration is a user-facing onboarding experience that captures security information for both Microsoft Entra MFA and SSPR in a single flow. It improves the likelihood that users register accurate methods, but it does not by itself enable the password reset feature. If SSPR is disabled, users still cannot reset their passwords regardless of how complete their security info is, so this option addresses registration convenience, not the reset capability itself.

Assign the 'Global Administrator' role to all users to allow password reset.

Why wrong: Making every user a Global Administrator is a severe privilege escalation that violates least privilege and expands the attack surface, since the Global Administrator role has tenant-wide control. While Global Administrators can reset passwords manually, that ability is an administrative function, not self-service reset for all users. Users should only need the SSPR permission granted by the SSPR feature, not a directory-wide administrative role, making this option wrong.

Create a log alert rule based on the VM's performance counters collected in Log Analytics.

Why wrong: Creating a log alert rule based on the VM's performance counters collected in Log Analytics is wrong for this scenario because log alerts depend on performance data being ingested into a Log Analytics workspace, which requires the Azure Monitor agent and diagnostic settings. This adds complexity and latency compared to a metric alert, which directly evaluates the VM's built-in platform metric. While log alerts are useful for complex cross-resource queries, they are not the optimal or most direct method for a single critical VM's CPU threshold alert.

Enable Azure Diagnostic Settings on the VM to send performance data to a storage account.

Why wrong: Enabling Azure Diagnostic Settings on the VM to send performance data to a storage account is wrong because diagnostic settings to a storage account are intended for archival, export, or compliance, not for real-time alerting. This action alone does not generate any alert; you would still need to create a log alert or external processing to analyze the stored data. For immediate CPU notification, a metric alert on the automatically available platform metric is the appropriate and efficient choice.

Configure an Application Insights availability test to monitor the VM's CPU.

Why wrong: Configuring an Application Insights availability test to monitor the VM's CPU is wrong because availability tests are designed to monitor the external reachability and response latency of HTTP/HTTPS endpoints, not server-side CPU utilization. They require a public URL and an agent to ping the endpoint from global locations, and they cannot read CPU metrics from an Azure VM. CPU monitoring belongs in Azure Monitor metrics, while availability tests belong to Application Insights web monitoring.

Changing the pricing tier of an App Service plan always causes downtime for all apps in the plan.

Why wrong: Changing the pricing tier of an App Service plan does not always cause downtime; the effect depends on the source and target tiers. For instance, scaling between tiers within the same scale unit, such as from Standard to Premium V3, is often performed as a seamless operation with no visible interruption. Even when a tier change requires reallocation, Azure typically uses rolling updates to maintain app availability, so the statement's blanket assertion is false.

An App Service plan can only contain apps from the same region and the same resource group.

Why wrong: While all apps in an App Service plan must be in the same region as the plan itself, they can absolutely belong to different resource groups. The resource group is a logical management boundary, not a technical constraint for App Service hosting. Therefore, the claim that apps must share both region and resource group is incorrect because it falsely conflates resource group membership with compute resource location.

The Free and Shared tiers support custom domain names and SSL binding without additional cost.

Why wrong: The Free tier does not support custom domain names at all, and the Shared tier, while supporting custom domains, does not offer custom-domain SSL binding. Even in tiers where SSL is available, binding a certificate to your domain typically requires a paid certificate or a Standard-tier plan at minimum. Thus, the assertion that Free and Shared tiers provide both custom domains and no-cost SSL binding is entirely inaccurate.

Blob SAS token

Why wrong: A blob SAS token is for blob data, not for mounting an Azure Files SMB share.

Network security group rule

Why wrong: NSG rules control traffic flow, but they do not authenticate file-share access.

Azure resource lock

Why wrong: A lock protects the storage account from changes, but it does not help clients mount the share.

Assign each policy only to one resource group.

Why wrong: Scoping the assignments to a single resource group would leave the other nine subscriptions (and all other resource groups) entirely ungoverned, creating severe compliance gaps. It also fragments governance: you would need many separate assignments for each resource group, and any new resource groups in those subscriptions would automatically lack the policy. A broader scope is necessary to meet the department's requirement of uniform governance across all 10 subscriptions.

Use Azure RBAC instead of Policy for both requirements.

Why wrong: Azure RBAC governs who can perform actions by defining roles and permissions, while Azure Policy governs what resource configurations are allowed or expected. Role assignments cannot enforce that resources are created only in a specific region or that every resource has a required tag—those are policy evaluation criteria outside RBAC's authorization model. Even with RBAC, a user with Contributor permissions could create a resource in any location unless a policy denies it.

Create a read-only lock on each subscription.

Why wrong: A read-only lock invokes a deny on all write and delete operations at the resource scope, but it is an operational safeguard, not a compliance control. It does not evaluate tags, cannot inspect resource properties for permitted regions, and does not produce policy compliance data. Locks are also applied uniformly and cannot conditionally allow or deny regions; they simply prevent modifications to locked resources.

D8as_v5

Why wrong: This is a smaller general-purpose size and does not provide enough memory for the workload.

F8s_v2

Why wrong: This family emphasizes compute density but falls short of the required memory capacity.

M8ms

Why wrong: This is a much larger memory-optimized size than needed and would overspend for the scenario.

Use an availability set and expect it to cover a zone outage.

Why wrong: An availability set uses fault domains and update domains to protect against hardware failures or patching events within a single datacenter, but it does not span across datacenters or availability zones. In Azure, fault domains in an availability set share the same power and network switch, so they remain within one zone. A zone outage or datacenter-level event (such as a fire or cooling failure) is far beyond what an availability set is designed to mitigate, leaving the entire set vulnerable. Therefore, using an availability set incorrectly assumes it can handle an outage that affects the whole building.

Keep all instances in one zone and rely on the load balancer.

Why wrong: A load balancer only distributes incoming traffic among healthy instances that are registered as backend targets, but it cannot create resilience against a failure at the infrastructure level. If all VM instances reside in the same availability zone, that zone's failure takes the entire backend down, and the load balancer will have no valid targets to route to, regardless of its own health. The load balancer itself may be zone-redundant (Standard SKU), but that only protects the front-end; the actual service still depends on a single zone for compute. Thus, relying on a load balancer without cross-zone instance placement does not satisfy the datacenter-failure requirement.

Use a paired region for automatic in-region zone balancing.

Why wrong: A paired region is a separate Azure region approximately 300 miles away that is used for disaster recovery during region-wide failures, not for balancing workloads within the same region. It provides asynchronous replication for some services and is a planned failover target, but invoking it introduces cross-region latency and requires a failover process. The requirement explicitly states that cross-region failover is not needed, so relying on a paired region would unnecessarily complicate the solution and does not address the immediate single-datacenter outage scenario. Azure's paired regions are not designed to automatically balance load across zones; they are for regional disaster recovery.

Azure Advisor

Why wrong: Azure Advisor is a personalized cloud consultant that analyzes your deployed resources and usage patterns to recommend best practices for cost optimization, security, reliability, and performance. It does not publish or surface real-time service incidents, outages, or maintenance events. Advisor focuses on improving your configuration based on telemetry, not on reporting the operational status of Azure itself, making it wrong for outage information.

Backup center

Why wrong: Backup center is a unified management experience for backup operations across your organization, allowing you to monitor backup jobs, configure policies, and manage restored items. It does not provide any incident, outage, or health status information about Azure platform services. Its purpose is operational management of backup and restore workflows, not service health monitoring, so it is incorrect for this use case.

Resource Graph

Why wrong: Resource Graph is a querying service that allows you to explore and inventory Azure resources across subscriptions using the Resource Graph query language. It gives you low-level metadata about resource type, location, tags, and properties, but it has no capability to report service incidents, health advisories, or outage status. It is designed for resource management and governance, not for monitoring the health of the Azure platform, so it is incorrect.

Use a system-assigned managed identity on only one VM and copy its access token to the other two VMs.

Why wrong: A system-assigned managed identity is intrinsically bound to a single VM and is deleted when that VM is deleted, so using it on only one VM and copying its access token to the other two is not a viable shared identity. Access tokens are short-lived (typically under 24 hours) and must be continuously refreshed, which would force the other VMs to depend on the one source VM remaining alive. Furthermore, extracting and replaying tokens outside the intended resource violates Azure's token-handling model and creates a security risk, because the token is not scoped to the other VMs' identities and cannot be renewed without accessing the original VM's identity endpoint.

Store one application password locally on each VM and use it instead of Azure-managed identities.

Why wrong: Storing an application password locally on each VM reintroduces the exact credential-management burden that managed identities eliminate. Passwords must be securely stored, rotated, and protected on every VM, and a leaked or stale password becomes a shared secret that an attacker can reuse across all three systems. Azure-managed identities, by contrast, are backed by Azure Active Directory and require no static secrets on the VM, so this option fundamentally fails the requirement to rely on an Azure identity that persists independently of VM lifecycle.

Delete the VM and recreate it from the OS disk.

Why wrong: Deleting a VM and attempting to recreate it from its OS disk is a destructive manual process that removes the VM resource, its NIC, public IP, and availability/extensions configuration; during the delete, the attached managed OS disk is typically retained only if explicitly kept, and reassociating it to a new VM requires re-creating all network and role settings from scratch. This is far more risky and time-consuming than redeploy or deallocate, and it unnecessarily exposes your workload to misconfiguration or accidental data loss. It does not address the underlying host health concern in a controlled way and should be avoided for a simple host-level performance issue.

Capture the VM into a generalized image.

Why wrong: Capturing a generalized image is a template-creation operation: it runs a generalization process (such as Sysprep for Windows or `waagent -deprovision` for Linux) that strips the VM of unique identifiers and user-specific configuration, then saves the disks as an image. This is inappropriate for troubleshooting a degraded VM because it converts the running system into a reusable template rather than restoring it to a healthy state, and the original VM cannot continue operation after generalization. It is a heavy, irreversible step that changes the VM's identity and requires creating new VMs from the image, so it does not address an unhealthy host.

Convert the VM to an availability set.

Why wrong: Converting a VM to an availability set is not an operational recovery action and is not even directly supported for an existing VM—you must create the availability set separately and then add the VM to it, which physically moves the VM into a different fault/update domain but does not necessarily trigger a new host placement or resolve current degradation. An availability set is a deployment topology that ensures VMs are placed on different physical infrastructure for high availability, not a troubleshooting tool for a single unhealthy VM. Attempting this would require a full recreate or a complex reconfiguration with downtime, making it completely unsuitable for immediate performance triage.

A ReadOnly lock is the best way to record department ownership.

Why wrong: A ReadOnly lock is the best way to record department ownership. A ReadOnly lock is an access-control mechanism that prevents any user from modifying or deleting the locked resource, regardless of their RBAC permissions. It is designed to protect critical infrastructure from accidental changes, not to label or classify resources. To record which department owns a resource, you should apply tag metadata, which is visible in reports and filters; a lock would merely block changes without providing any ownership information.

Tags automatically encrypt the data in a resource.

Why wrong: Tags automatically encrypt the data in a resource. This is false because tags are metadata only and do not touch the resource's data plane. Encryption is controlled by Azure Storage Service Encryption, Azure Disk Encryption, or SQL TDE, among other mechanisms, and is configured through the resource's settings, not through tag key-value pairs. Adding or changing a tag does not alter the encryption state or otherwise affect the security posture of the protected data.

Tags replace Azure Policy when compliance must be enforced.

Why wrong: Tags replace Azure Policy when compliance must be enforced. This is incorrect because tags are only descriptive metadata; they do not evaluate or enforce any rules. Azure Policy is the service that can audit, deny, or auto-remediate resources that do not follow required tagging standards, such as a mandatory department tag, but the policy engine is separate from the tag itself. While tags can be the subject of policy definitions, they cannot enforce anything on their own, so they do not replace policy.

Place the VMs in an availability set instead of using a scale set.

Why wrong: An availability set is designed for high availability by distributing VMs across fault domains and update domains, but it does not include any built-in mechanism to automatically add or remove VMs. If the workload grows, an administrator must manually create and attach new VMs; likewise, reducing capacity requires manual deallocation. While an availability set improves resilience, it fails the core requirement of automatic scaling based on CPU utilization, so it is not a substitute for a VM scale set in this scenario.

Clone the VM manually whenever CPU rises and remove clones by hand later.

Why wrong: Manually cloning a VM whenever CPU rises and removing clones by hand is operationally fragile and violates the requirement for automatic scaling. Manual actions are slow relative to load changes, prone to configuration drift because cloned instances must be individually updated, and offer no centralized monitoring or safe scale-in logic. This approach also requires continuous human attention and lacks the integration with autoscale policies that a purpose-built VMSS provides, making it both inefficient and unreliable for a dynamic workload.

Use a Premium SSD OS disk so the reimage is preserved.

Why wrong: Selecting a Premium SSD OS disk does not preserve the OS disk across a reimage; the reimage operation always resets the OS disk to the original image state, regardless of whether it uses Standard or Premium storage. Premium SSD only offers higher IOPS and throughput, which are unnecessary for a build agent that explicitly tolerates losing the OS. Additionally, paying premium costs for a disk that is discarded every night is wasteful, making an ephemeral OS disk the cheaper and equally functional alternative.

Store the caches only on the temporary resource disk.

Why wrong: The temporary resource disk is a host-local SSD intended for scratch space, not durable storage. It is cleared when the VM is reimaged, deallocated, migrated, or when service healing occurs, so data placed there disappears exactly when the build agent is rebuilt. Because the scenario requires caches and artifacts to persist across nightly reimages, the temporary disk is completely unsuitable—this is a textbook case for a managed data disk instead.

Use an availability set to make the OS disk persistent.

Why wrong: An availability set is a logical grouping that spreads VMs across fault and update domains to improve resilience against hardware failures and patching windows. It has no effect on disk persistence: the OS disk of any VM in the set is still reset during a reimage, and durability is determined solely by the disk type, not by the availability feature. Using an availability set would be useful for managing multiple build agents, but it does not make a single OS disk persistent.