AZ-900 Describe cloud concepts Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Create load balancer -> Configure frontend IP and backend pool -> Configure health probes -> Configure load balancing rules -> Associate VMs to backend pool

  Why this is correct

  This order ensures each step builds on previous configurations: the load balancer must exist before IP/pool config, health probes require a backend pool, rules require probes, and VMs must be associated after everything else is set.

• ✗

  Associate VMs to backend pool -> Create load balancer -> Configure frontend IP and backend pool -> Configure health probes -> Configure load balancing rules

  Why it's wrong here

  Associating VMs to a backend pool as the very first action is invalid because the backend pool itself is a child resource of the Azure Load Balancer and does not exist yet. The association operation requires the pool's resource ID, which is only generated after the load balancer is created and the pool is configured. In fact, the third step attempts to create the pool, so the initial VM binding references a non-existent pool and would fail with a resource-not-found error. The correct sequence must first establish the load balancer and its pool, then bind VMs.

• ✗

  Create load balancer -> Configure frontend IP and backend pool -> Configure load balancing rules -> Configure health probes -> Associate VMs to backend pool

  Why it's wrong here

  Creating load balancing rules before the health probe is invalid because every rule must reference an existing probe to determine backend health. The rule's configuration includes a probe selector, and Azure validates that the referenced probe exists at creation time; otherwise, the operation fails. Additionally, even if a 'None' probe were permitted, the intended high-availability setup would be broken because the load balancer would not monitor backend health. Therefore, the probe must be provisioned before the rule.

• ✗

  Configure frontend IP and backend pool -> Create load balancer -> Configure health probes -> Configure load balancing rules -> Associate VMs to backend pool

  Why it's wrong here

  Beginning with the frontend IP and backend pool before the load balancer resource itself is impossible because these are child resources that must be scoped within a parent load balancer. In Azure Resource Manager, child resources cannot be created independently; they require the parent to exist first to provide the hierarchical namespace. The portal workflow enforces this by not offering these configuration blades until a load balancer is created. Thus, this ordering attempts to provision resources that have no parent container, causing a validation error immediately.

Go deeper

Related to this question