AZ-305 Design infrastructure solutions 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 endpoint, then approve, then configure DNS, then test, then disable public access

  Why this is correct

  This is the correct order because the endpoint must be created before it can be approved, DNS must be configured after approval to ensure proper name resolution, testing validates connectivity before disabling public access, and public access is disabled last to secure the database.

• ✗

  Create endpoint, then approve, then test, then configure DNS, then disable public access

  Why it's wrong here

  Placing the test step before DNS configuration is invalid because a connectivity test resolves the Azure resource's fully qualified domain name (FQDN) through normal DNS, which at that point still points to the public IP address rather than the private endpoint IP. Even if the test succeeds, it would be exercising the public endpoint or falling back to it, so it does not validate the private link path. DNS must be configured after approval to map the FQDN to the private IP; only then can the test meaningfully confirm that traffic is traversing the private endpoint.

• ✗

  Approve, then create endpoint, then configure DNS, then test, then disable public access

  Why it's wrong here

  Approval cannot happen before the private endpoint exists because the approval workflow acts on a pending private endpoint connection request that the target resource receives. When a private endpoint is created, it triggers a connection request in a 'Pending' state; only then can the target resource owner review and approve that specific request. Attempting to approve first would leave no connection request to act upon, and Azure would return an error or the operation would be a no-op, so the correct first step is always creating the endpoint.

• ✗

  Create endpoint, then configure DNS, then approve, then test, then disable public access

  Why it's wrong here

  Configuring DNS before approval is incorrect because the private IP address that should be inserted into the private DNS zone is only truly usable after the connection is approved and the endpoint provisioning completes. Until approval, the private endpoint connection remains in a pending state, so any DNS record you create would either point to an address that is not ready or be overwritten when the system later provisions the endpoint. The proper workflow approves the endpoint first, establishing the active connection, and then configures DNS to map the FQDN to that approved private IP, ensuring name resolution matches the actual network path.

Go deeper

Related to this question