DP-900 Practice Question: Describe considerations for working with non-relational data on Azure

Answer analysis

Option-by-option breakdown

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

• ✓

  Identify the client IP address, then add a firewall rule with that IP range to the Azure SQL Server, then save the rule.

  Why this is correct

  This order is correct because the client's public IP address is the key parameter of any Azure SQL firewall rule; without knowing it, the rule has no valid source. You must first identify the exact IP (or CIDR range) the client will use to connect, then create the rule at the Azure SQL Server level, and finally click Save to persist the rule. Saving after adding makes the rule active; any other sequence either leaves the rule ineffective or introduces unnecessary security exposure.

• ✗

  Add a firewall rule with a broad IP range to the Azure SQL Server, then identify the client IP address, then save the rule.

  Why it's wrong here

  Broadening the IP range before knowing the client's actual address is a security anti-pattern because it may permit traffic from an entire subnet or range of unrelated public IPs, increasing the attack surface. Furthermore, if the broad range does not actually encompass the client's real IP, the rule will fail to grant access, and you will still need to identify the IP and then modify or replace the rule. The correct approach is to first pinpoint the client IP, then create a narrowly scoped rule that matches only that source.

• ✗

  Add a firewall rule to the Azure SQL Server, save the rule, then identify the client IP address.

  Why it's wrong here

  Saving a firewall rule before its source IP is identified is operationally impossible because the rule must contain the IP address as its core attribute; Azure SQL will reject a rule definition that lacks a valid start and end IP. Even if the Portal allowed you to create a placeholder, saving it would either generate an incomplete rule or require you to later return and edit the rule, causing additional API calls and a risk of leaving the database exposed. The sequence therefore violates the dependency: the IP must be known before the rule is authored and persisted.

• ✗

  Identify the client IP address, then save the rule, then add a firewall rule to the Azure SQL Server.

  Why it's wrong here

  This order is invalid because the Azure SQL firewall is a set of rules that are first added (created) and then saved (persisted); there is no object to save before the rule exists. In the Azure Portal and API, the act of adding a rule defines its properties, and only then does Save/Apply send the configuration to the database service. Attempting to save before adding would either fail with an error or, if interpreted as saving changes, still require the rule to be added first—making the 'save' step meaningless.

Go deeper

Related to this question