SC-100 Practice Question: Order the steps to configure Azure Key Vault…

Answer analysis

Option-by-option breakdown

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

• ✓

  Enable service endpoint on subnet, then add virtual network rule in Key Vault firewall, then (optionally) allow trusted Microsoft services, then save the firewall configuration.

  Why this is correct

  This is the correct order because the service endpoint must be enabled on the subnet before you can add a virtual network rule referencing that subnet. After adding rules, you may choose to allow trusted Microsoft services, and finally save all changes.

• ✗

  Add virtual network rule in Key Vault firewall, then enable service endpoint on subnet, then save, then allow trusted Microsoft services.

  Why it's wrong here

  Attempting to add a virtual network rule to the Key Vault firewall before enabling the Microsoft.KeyVault service endpoint on the subnet fails because the rule cannot resolve or validate the subnet as an allowed source. Azure Key Vault's firewall only accepts virtual network rules for subnets that have the service endpoint explicitly activated, as that endpoint ensures all traffic to the vault is routed through the Microsoft backbone. Without the service endpoint, the rule is either rejected by the API or silently ignored, meaning traffic from that subnet would still be blocked. Additionally, while saving and enabling trusted Microsoft services at the end are correct, the critical dependency is that the service endpoint must precede the rule creation.

• ✗

  Enable service endpoint on subnet, then save the firewall configuration, then add virtual network rule, then allow trusted Microsoft services.

  Why it's wrong here

  Saving the firewall configuration immediately after enabling the service endpoint but before adding the virtual network rule commits a state where no network rules exist, so the Key Vault will continue to deny traffic from the subnet if the default action is 'Deny'. The save operation persists the current rules, and since the rule is absent at that moment, the firewall is locked down and you would need a second, separate update to add the rule—introducing an unnecessary and possibly lengthy window of misconfiguration. This ordering mistake is especially dangerous because if the firewall explicitly denies all other sources, the vault becomes temporarily inaccessible before the rule is added. The correct sequence is to add the virtual network rule as part of the same editing session, then save once all intended rules are in place.

• ✗

  Allow trusted Microsoft services, then enable service endpoint, then add virtual network rule, then save.

  Why it's wrong here

  Turning on the 'Allow trusted Microsoft services' exception before defining network rules is misleading because that bypass applies to all trusted services, effectively weakening the firewall before you have even established the baseline access controls. The intended order is to first configure and save the network rules—such as the virtual network rule—and only then, if needed, add the trusted services exception so that you are explicitly aware of what is being allowed beyond your network boundaries. Additionally, the service endpoint must be enabled on the subnet before adding the virtual network rule, and this sequence incorrectly places the trusted services toggle first, which has no dependency on the service endpoint. The final save should occur only after all rules and exceptions are set, but here saving is correctly last while the earlier steps are in an invalid order.

Go deeper

Related to this question