AZ-104 Azure compute resources: 169 practice questions
7-day money-back guarantee — full refund within 7 days of purchase if you've completed under 20% of the questions. See pricing →
Certifications Tools Flashcards Career Paths Exam Guides Blog Pricing For Teams About

Language

✓ EnglishDeutschEspañolFrançaisPortuguês
Check readiness — free →

AZ-104 Deploy and manage Azure compute resources: 169 practice questions

AZ-104 169 questions 12 shown free

12 of the 169 Deploy and manage Azure compute resources questions in the Certsqill AZ-104 bank, shown in full below. Each one carries an explanation for every option, not just the correct one — the wrong answers are where the marks go.

Preparing for AZ-104? Take the free 5-min readiness check →

1. Incremental deployment mode: Which deployment mode should the administrator use?

Easy
You have an Azure subscription. You must deploy a Bicep template to an existing resource group to add a virtual machine. The resource group also contains several manually managed resources that are intentionally absent from the template and must remain unchanged. Which deployment mode should the administrator use?
  1. Assign an Azure Policy in audit mode before deploying
    Audit policy reports compliance state; it does not select the ARM deployment behavior or preserve omitted resources.
  2. Apply a CanNotDelete resource lock to the resource group before deploying
    A CanNotDelete lock blocks control-plane deletion but does not provide the required deployment mode and is not the mechanism for retaining omitted resources.
  3. Complete deployment mode
    Complete mode can delete resources omitted from the template, so it risks removing the manually managed resources.
  4. Incremental deployment mode ✓
    Incremental mode leaves resources omitted from the template in place while deploying the resources declared in the template.
The trap
Do not confuse a deletion lock or Azure Policy with deployment behavior; identify whether omitted resources must remain in scope.

Use incremental mode because resources absent from the template remain in the resource group.

2. Update the Bicep template so the virtual machine satisfies: What should you do?

Medium
You have an Azure subscription. You deploy a virtual machine from a Bicep template to a resource group. The deployment is denied because an Azure Policy assignment inherited from the management group disallows the submitted resource properties. The administrator has deployment permissions and must complete the deployment without weakening governance. What should you do?
  1. Change the deployment to complete mode so the resource is created despite the policy assignment.
    Deployment mode does not bypass policy evaluation. Complete mode can also delete resources omitted from the template, so it is not a solution to this denial.
  2. Update the Bicep template so the virtual machine satisfies the policy requirements, then redeploy it. ✓
    Policy evaluates resource properties and a deny effect blocks a noncompliant new or updated resource operation. Correcting the template addresses the effective policy decision.
  3. Grant the administrator an additional Azure RBAC role at the resource-group scope and redeploy the unchanged template.
    RBAC authorizes user actions, but it does not make resource properties compliant with Azure Policy. The inherited deny still applies.
  4. Assign an audit policy at the resource-group scope and redeploy the unchanged template.
    An audit assignment reports noncompliance but does not replace or neutralize the inherited deny assignment. The unchanged operation remains blocked.
The trap
When a deployment is denied for resource properties, fix the template or effective policy scope; extra RBAC permissions do not bypass Azure Policy.

Update the template to comply with the inherited policy, then redeploy. RBAC and deployment mode do not override a policy deny.

3. Apply CanNotDelete to the storage account: Which action is still required?

Hard
You have an Azure subscription that contains a resource group with a virtual machine and a storage account. The administrator places a CanNotDelete lock on the virtual machine and deploys an incremental ARM template that declares the virtual machine but omits the storage account. Both the VM and the storage account must remain updateable, omitted resources must remain, and the storage account must not be deleted through the control plane. Which action is still required?
  1. Assign an audit policy requiring deletion protection to the resource group.
    An audit policy reports compliance state; it does not itself block a control-plane deletion. Azure Policy and locks provide different controls.
  2. Apply a ReadOnly lock to the storage account.
    This would block updates as well as deletion, exceeding the stated requirement. It is also unnecessary when CanNotDelete is sufficient.
  3. Change the deployment mode to complete.
    Complete mode can delete resources omitted from the template, contradicting the requirement that the omitted storage account remain.
  4. Apply CanNotDelete to the storage account. ✓
    The VM lock does not protect the storage account. A CanNotDelete lock at the storage account or inherited resource-group scope blocks control-plane deletion while allowing authorized updates.
The trap
Distinguish CanNotDelete from ReadOnly, and distinguish ARM control-plane locks from policy evaluation and deployment mode.

The VM's CanNotDelete lock does not protect the separate storage account. Add a CanNotDelete lock at the storage account or an inherited resource-group scope.

4. Include the required non-default property value: What should be changed?

Medium
You have an Azure subscription. You redeploy an existing resource in incremental ARM mode. The template omits a property that previously had a non-default value. The administrator needs that non-default value preserved. What should be changed?
  1. Switch to complete deployment mode without adding the property.
    Complete mode is not a property-preservation mechanism and can delete omitted resources.
  2. Include the required non-default property value in the resource definition before redeployment. ✓
    Properties on declared resources are reapplied; explicitly including the desired non-default value avoids a reset to its default.
  3. Apply an audit policy without changing the resource definition.
    An audit policy reports compliance but does not supply the missing desired property value.
  4. Leave the property omitted because incremental mode preserves every unspecified property.
    Incremental mode preserves omitted resources, not necessarily omitted properties of declared resources.
The trap
Properties on declared resources are reapplied; explicitly including the desired non-default value avoids a reset to its default.

Properties on declared resources are reapplied; explicitly including the desired non-default value avoids a reset to its default.

5. Deploy application VMs across availability zones: Which action should the administrator take?

Easy
Your company runs a production workload on one VM in a supported Azure region. The requirement is to keep the workload available if one datacenter in that region fails. Which action should the administrator take?
  1. Deploy application VMs across availability zones in the region. ✓
    Availability zones isolate datacenter failures within a supported region, and multiple VM instances should be placed in different zones.
  2. Enable Azure VM backup using a Recovery Services vault in the VM's region.
    VM backup can provide recovery points after protection is configured and a recovery point exists, but it does not keep the workload available during a datacenter failure.
  3. Resize the existing VM to a larger VM size.
    Resizing one VM is scale-up; it does not add another instance or isolate the workload across datacenters.
  4. Place multiple VM instances in an availability set in the same region.
    An availability set provides infrastructure fault and update separation, but it does not provide the stated datacenter-failure isolation offered by different zones.
The trap
Distinguish availability from recoverability: zones and availability sets support running workloads, while backup provides recovery points.

Use multiple VM instances in different availability zones. Zones isolate datacenter failures within a supported region; availability sets, resizing, and backup do not meet this availability requirement.

6. Create or use a Recovery Services vault in East US: What should you do to establish valid VM backup protection

Medium
You have an Azure subscription. A VM runs in East US. You propose using an existing Recovery Services vault in West US with a daily backup policy. Protection has not yet been enabled. What should you do to establish valid VM backup protection?
  1. Keep the West US Recovery Services vault and wait for the daily policy to create the first recovery point.
    Waiting does not correct the vault’s region: VM backup uses a Recovery Services vault in the same region as the VM.
  2. Create or use a Recovery Services vault in East US, configure the backup policy, and verify a completed backup job and recovery point. ✓
    Azure VM backup requires a Recovery Services vault in the VM’s region, and configured protection is not proof that a recovery point exists.
  3. Place the VM in an availability zone in East US so its disks are protected against future failures.
    Availability zones provide infrastructure-failure isolation; they do not establish VM backup or create recovery points.
  4. Create a Backup vault in East US and move the existing VM backup policy to that vault.
    A Backup vault is a different resource type; the supplied VM backup requirement is a Recovery Services vault.
The trap
Distinguish backup configuration from successful protection: always check both the vault’s region and an actual recovery point.

Use a same-region Recovery Services vault and confirm an actual recovery point; configuration alone is insufficient.

7. Add a VM in another local availability zone and distribute: Which action should the administrator take?

Hard
You have an Azure subscription. An application currently runs on one VM in availability zone 1 of a supported Azure region. The stateless application supports multiple instances. It must remain available if one datacenter in that region fails. The administrator wants to make the smallest architectural change that addresses this availability requirement. Which action should the administrator take?
  1. Add a VM in another local availability zone and distribute application traffic. ✓
    This places multiple VM instances in separate zones, isolating them from a datacenter failure within the supported region.
  2. Resize the existing VM to a larger size with more compute capacity.
    Resizing changes the capacity of one VM; it does not add another instance or isolate instances across datacenters.
  3. Enable Azure VM backup by selecting a Recovery Services vault in the same region.
    A same-region Recovery Services vault is required for VM backup, but configuring backup provides recovery points rather than continuous availability during a datacenter failure.
  4. Deploy a second VM in the same availability set as the existing VM.
    An availability set separates VMs across infrastructure fault and update domains, but it does not provide the stated datacenter-isolation guarantee of different availability zones.
The trap
Distinguish zone-based availability from availability sets, backup, and vertical resizing: only zones provide the stated datacenter-failure isolation.

Use multiple VM instances in different availability zones within the supported region. Availability sets, backup, and resizing address different concerns.

8. Use an East US Recovery Services vault: What is the smallest corrective action that establishes valid VM backu

Medium
You have an Azure subscription. You must protect a VM named AppVM in East US. The administrator has configured a backup policy, but the only existing Recovery Services vault is in West US. AppVM has not yet produced a recovery point. What is the smallest corrective action that establishes valid VM backup and confirms protection?
  1. Leave the current vault configuration unchanged because assigning the policy proves that AppVM has a usable backup.
    A policy defines schedule and retention, but assigning protection is not proof that a recovery point has completed.
  2. Use an East US Recovery Services vault; set the required policy and confirm an AppVM recovery point. ✓
    Use the correct regional vault and configure its own policy; then verify a completed backup rather than assuming that configuration proves recovery-point availability.
  3. Associate AppVM with the existing West US Recovery Services vault and verify the next recovery point.
    The vault is in a different region from AppVM, so it does not satisfy the stated regional requirement for Azure VM backup.
  4. Create a Backup vault in East US and associate AppVM with the existing backup policy.
    A Backup vault is a different resource type from the Recovery Services vault required for Azure VM backup in this scenario.
The trap
Separate backup configuration from backup success: a policy assignment is not evidence that a recovery point exists.

Use a same-region Recovery Services vault, apply the policy, and verify a completed recovery point.

9. Configure a Virtual Machine Scale Set with scheduled: Which configuration should it use?

Medium
Your company operates a VM-based application. A stateless application runs on Azure VMs. Demand follows a predictable daily peak. The team wants Azure to increase and decrease the number of identically configured VM instances on a schedule. Which configuration should it use?
  1. Place the existing VMs in an availability set without scaling rules.
    Availability placement does not by itself adjust the VM count on a schedule.
  2. Configure a Virtual Machine Scale Set with scheduled autoscale rules. ✓
    A scale set can adjust instance count according to a schedule, directly meeting the requested scale-out and scale-in behavior.
  3. Configure a VM backup policy with a daily schedule.
    Backup scheduling creates recovery points, not compute scaling.
  4. Resize one VM to a larger size before each peak.
    Resizing changes one instance’s capacity rather than automatically changing the number of instances.
The trap
A scale set can adjust instance count according to a schedule, directly meeting the requested scale-out and scale-in behavior.

A scale set can adjust instance count according to a schedule, directly meeting the requested scale-out and scale-in behavior.

10. Review the vault’s backup jobs and confirm a completed: Which action should the administrator take?

Easy
You have an Azure subscription that contains a VM protected by a Recovery Services vault in the VM’s region. The administrator must verify that the requested backup has actually completed and produced recoverable data. Which action should the administrator take?
  1. Review the backup policy’s schedule and retention settings.
    The policy describes when backups should run and how long they should be retained; it does not verify an actual completed recovery point.
  2. Verify that the Recovery Services vault exists in the same region as the VM.
    Matching regions satisfy the vault placement requirement, but vault existence alone does not verify backup completion or recoverability.
  3. Review the vault’s backup jobs and confirm a completed recovery point exists for the VM. ✓
    Completed backup jobs and recovery points directly verify that backup produced recoverable data.
  4. Confirm that the VM is listed as protected in the Recovery Services vault.
    Protection configuration shows that backup is configured, but it does not prove that a backup has completed.
The trap
For backup verification, distinguish configuration from outcome: look for completed jobs or recovery points.

Check completed backup jobs and recovery points, not merely protection configuration, policy settings, or vault placement.

11. Set the ACI restart policy to OnFailure: Which configuration should the administrator use?

Hard
You have an Azure subscription. You run a short-lived container in Azure Container Instances. The container must be restarted when its main process exits with a nonzero status, but it should not be restarted after successful completion. Which configuration should the administrator use?
  1. Deploy the container to Azure Container Apps and configure a minimum replica count of one.
    A minimum replica count maintains a baseline of replicas; it does not configure ACI-style retries based on the container process exit status.
  2. Set the ACI restart policy to Never.
    Never does not provide the required restart after a nonzero process exit.
  3. Set the ACI restart policy to OnFailure. ✓
    OnFailure restarts the container after a nonzero process exit and does not restart it after successful completion.
  4. Set the ACI restart policy to Always.
    Always restarts the container after termination, including successful completion, so it does not meet the requirement.
The trap
Distinguish ACI restart policies from replica scaling: OnFailure is based on process exit status, whereas a replica minimum controls baseline replicas.

Use the ACI OnFailure restart policy because the required retry condition is a nonzero process exit, while successful completion must not trigger a restart.

12. Add an HTTP concurrency scale rule: Which change should the administrator make to enable HTTP-based scaling wh

Medium
You have an Azure subscription. You manage a Container App that receives HTTP traffic. Its current configuration has minimum and maximum replicas set to 0 and 1, respectively, with no scale rule. During traffic bursts, the single replica becomes overloaded, but the administrator expects Azure to add replicas automatically. Which change should the administrator make to enable HTTP-based scaling while retaining a baseline instance?
  1. Keep the replica range at 1 to 1 and increase the container's CPU allocation.
    Increasing CPU changes capacity per replica, but a maximum of one prevents replica-count scaling and no HTTP scale rule is configured.
  2. Set the container restart policy to OnFailure so the platform creates another instance when the current one is overloaded.
    OnFailure is an ACI restart-policy behavior for nonzero process exits; it is not the Container Apps mechanism for HTTP-based replica scaling.
  3. Change the maximum replicas to 5 while leaving the minimum at 0 and leaving scale rules unset.
    Raising the maximum only permits additional replicas; without an HTTP or supported event-driven scale rule, the desired traffic-based scaling trigger is absent.
  4. Add an HTTP concurrency scale rule, and set minimum replicas to 1 and maximum replicas to 5. ✓
    This configures Container Apps to scale declaratively from HTTP concurrency and keeps one baseline replica running.
The trap
Separate per-replica resource sizing and restart behavior from Container Apps replica autoscaling: HTTP or event-driven rules trigger scaling.

Use a Container Apps HTTP concurrency scale rule with minimum replicas set to 1 and a higher maximum.

157 more Deploy and manage Azure compute resources questions

The remaining 157 questions in this domain are part of the full AZ-104 bank — 722 questions, every option explained. Start with the free five-minute check and see your score per domain.

Test your AZ-104 readiness — free

Other AZ-104 domains

Part of the Certsqill AZ-104 question bank · Deploy and manage Azure compute resources · Every answer, right and wrong, comes with its own explanation.