Skip to main content

Technical Lab: Configure service endpoint policies

Questions​

Question 1 — Multiple Choice​

A security team needs to ensure that a subnet in an Azure VNet can access only a specific storage account, and not any storage account from the organization or other organizations. The service endpoint feature is already enabled on the subnet for Microsoft.Storage.

Which complementary feature should be configured to meet this requirement?

A) Network Security Group (NSG) with an outbound rule blocking the Storage service tag

B) Service endpoint policy associated with the subnet, referencing the specific storage resource

C) Azure Firewall with an application rule pointing to the storage account's FQDN

D) Private endpoint created in the subnet for the target storage account

Question 2 — Technical Scenario​

A team configured a service endpoint policy on a subnet and properly associated it. After the configuration, developers report they can no longer access an Azure Data Lake Storage Gen2 that was working before. The policy was created with the following definition:

{
  "serviceEndpointPolicyDefinitions": [
    {
      "service": "Microsoft.Storage",
      "serviceResources": [
        "/subscriptions/aaaa-bbbb/resourceGroups/rg-prod/providers/Microsoft.Storage/storageAccounts/contosoprod"
      ]
    }
  ]
}

What is the most likely cause of the Data Lake Storage Gen2 access failure?

A) Service endpoint policies don't support the Microsoft.Storage type, requiring a separate type for Data Lake

B) The Azure Data Lake Storage Gen2 is in a different subscription and policies don't allow cross-subscription references

C) The policy only allows the contosoprod account, and Data Lake Storage Gen2 is a distinct storage account not listed in the policy

D) The serviceResources field only accepts resource groups, not individual resources

Question 3 — True or False​

A service endpoint policy can be associated with multiple different subnets, even if those subnets belong to different VNets within the same region.

Question 4 — Technical Scenario​

An architect needs to restrict subnet access so it can only reach Azure Storage resources belonging to their own organization, without specifying each account individually. They consider using the following value in the serviceResources field:

/subscriptions/aaaa-bbbb-cccc-dddd

Would this approach work as expected?

A) Yes, subscription-level scope is supported and will allow access to all storage accounts in that subscription

B) No, because service endpoint policies require each resource to be specified individually at the resource account level

C) Yes, but only if the subscription is in the same tenant as the VNet

D) No, because the minimum supported scope is the resource group, and subscriptions are not accepted as scope

Question 5 — Multiple Choice​

When associating a service endpoint policy with a subnet, what is the resulting behavior for traffic destined to the service referenced in the policy?

A) All traffic from the subnet to the service is blocked by default, and only resources explicitly listed in the policy are allowed

B) Traffic to resources not listed in the policy is redirected via the internet, bypassing the service endpoint

C) The policy only affects inbound traffic to the subnet, with no impact on outbound traffic to the service

D) The policy is only applied when combined with an NSG outbound rule with the same service tag

Answer Key and Explanations​

Answer Key — Question 1​

Answer: B

Service endpoint policies were created exactly to solve this scenario: restricting traffic that already uses service endpoints to reach only specific resources within a service. Without the policy, the service endpoint ensures optimized routing to any resource of that service, including accounts from other organizations.

The main conceptual error in the distractors is confusing the purpose of the tools. The NSG (A) controls access by IP or entire service tag, without granularity per individual resource. Azure Firewall (C) can filter by FQDN, but it's not the native and designated mechanism for this control over service endpoints. The private endpoint (D) solves isolation through a different mechanism and is not related to service endpoint policies.

Answer Key — Question 2​

Answer: C

The service endpoint policy works as an explicit allow list: only resources listed in serviceResources are accessible by the subnet via service endpoint. Azure Data Lake Storage Gen2 is, internally, a separate storage account. If it's not listed in the policy, traffic to it will be blocked, even though the Microsoft.Storage service is enabled on the subnet.

Distractor A is incorrect because Microsoft.Storage covers both Blob Storage and Data Lake Storage Gen2 within the same service type. Distractor B is incorrect because cross-subscription references are supported in service endpoint policies. Distractor D represents a common confusion, as the serviceResources field accepts both individual resources and resource groups and subscriptions as scopes.

Answer Key — Question 3​

Answer: False

A service endpoint policy can be associated with multiple subnets, but those subnets need to belong to the same region as the policy and also to the same VNet or VNets in the same region. The critical point is that the policy itself has regional scope: it's a regional resource and can only be associated with subnets in the same region where it was created. Belonging to different VNets in the same region is allowed, but the statement as presented creates ambiguity by omitting the region restriction, being technically false as an unrestricted general rule.

This behavior is relevant in hub-spoke topology planning, where subnet policies need to be replicated per region, not reused globally.

Answer Key — Question 4​

Answer: A

The serviceResources field in service endpoint policies supports three scopes: individual resource, resource group, and subscription. Specifying a subscription ID is valid and will make all resources of that service within that subscription allowed. This is a common approach when the organization wants to control access at the subscription level without enumerating each account individually.

Distractor B incorrectly denies support for broad scopes. Distractor C introduces a tenant restriction that doesn't exist in the feature specification. Distractor D inverts the hierarchy: subscription is a broader scope than resource group, and both are supported.

Answer Key — Question 5​

Answer: A

This is the fundamental behavior of service endpoint policies: they act as an allowlist over traffic that is already routed by the service endpoint. Service resources not listed in the policy are blocked, even if the service endpoint is enabled. The blocking applies to outbound traffic from the subnet destined to the service.

Distractor B represents a dangerous misconception: traffic is not redirected to the internet, it is simply blocked. Distractor C inverts the direction: policies control outbound traffic from the subnet to the service, not inbound. Distractor D is incorrect because the policy operates independently of NSG rules; it is applied directly over the service endpoint, without need for additional NSG configuration.