4 of the 6 questions we have for this objective, shown with the answer and the reasoning.
Design and implement service endpoints
Cobalt Engineering enables the Microsoft.Storage service endpoint on subnet snet-ci (10.130.6.0/24) of VNet-Build in the UK South region. The storage account stcobaltartifacts, also in UK South, has public network access set to Enabled from selected virtual networks and IP addresses, but the build agents in snet-ci receive 403 AuthorizationFailure errors when they upload artifacts. The agents have no public IP addresses, and an NSG on snet-ci already allows outbound traffic to the Storage service tag.
What should you do to allow the build agents to upload?
- AAdd a virtual network rule on stcobaltartifacts that selects VNet-Build and the subnet snet-ci.Enabling the endpoint on the subnet is only half of the configuration; the storage account firewall must list the subnet as an allowed virtual network for traffic from it to be authorized.
- BAdd the address range 10.130.6.0/24 to the firewall IP address rules of stcobaltartifacts.IP address rules only accept public IP addresses; private ranges are rejected, and traffic over a service endpoint is identified by subnet rather than by IP address.
- CEnable the exception for trusted Azure services on stcobaltartifacts.The trusted services exception admits specific Microsoft platform services such as Azure Backup or Azure Monitor, not customer virtual machines in a subnet.
- DChange the NSG on snet-ci to allow outbound traffic to the Internet service tag.The NSG already permits the Storage service tag, and a 403 from the storage service indicates the request arrived and was rejected by the storage firewall, not blocked by the NSG.
Why: Configuring access through a service endpoint is a two-sided task: the subnet must have the endpoint enabled, and the target resource firewall must contain a virtual network rule that references that subnet. A 403 AuthorizationFailure proves the request reached the storage account and was rejected by its firewall rather than dropped by the network, which points to the missing virtual network rule. The deciding details are that the agents have no public IP addresses and that the NSG already allows storage traffic, so IP rules and NSG changes cannot be the answer. The trusted services exception is a trap because it applies only to Microsoft platform services, not to customer compute.
Design and implement service endpoints
Pinecrest Health enables the Microsoft.Storage service endpoint on subnet snet-export (10.120.5.0/24) so that export servers can write to the storage account stpinecrestexports in resource group rg-exports. A security review finds that any server in snet-export can also upload data to any other storage account in Azure, including accounts in other subscriptions. The team must restrict outbound storage traffic from snet-export to stpinecrestexports only, without adding a firewall appliance.
Which two actions should you perform? Each correct answer presents part of the solution.
- ACreate a service endpoint policy with a policy definition for Microsoft.Storage whose resource list contains the resource ID of stpinecrestexports.A service endpoint policy definition scopes which Azure Storage resources are reachable through the endpoint; listing the exact resource ID limits traffic to that one account.
- BAssociate the service endpoint policy with subnet snet-export.A policy only takes effect when associated with a subnet that has the Microsoft.Storage service endpoint enabled; this binds the restriction to the export servers.
- CCreate a service endpoint policy with a policy definition for Microsoft.Sql that lists stpinecrestexports.Service endpoint policies are supported only for Azure Storage; Microsoft.Sql is not a valid service in a policy definition.
- DAssociate the service endpoint policy with the storage account stpinecrestexports.Policies are associated with subnets, not with storage accounts; the storage account is the target listed inside the policy definition.
- EAdd an outbound network security group rule on snet-export that allows the Storage service tag and denies all other internet traffic.The Storage service tag covers every Azure Storage account, not a single resource, so this rule still permits uploads to arbitrary accounts and does not restrict access to stpinecrestexports.
Why: Service endpoints by themselves let a subnet reach the entire Azure Storage service, which creates a data exfiltration risk. Service endpoint policies close that gap by listing exactly which storage resources, resource groups, or subscriptions a subnet may reach through the endpoint. Two pieces are needed: a policy whose definition names the allowed resource, here the resource ID of stpinecrestexports, and an association of the policy with the subnet that has the endpoint. The deciding constraint is exact-resource restriction without a firewall appliance. The traps are the Microsoft.Sql definition, because policies support only Azure Storage, and the Storage service tag in an NSG, which is far too broad to meet the requirement.
Design and implement service endpoints
Pinecrest Health has application servers in subnet snet-app (10.120.3.0/24) of VNet-Clinic in the West US region, with the Microsoft.Storage service endpoint already enabled. A new storage account named stpinecrestdr was created in the East US 2 region for disaster recovery copies. When an administrator tries to add snet-app as a virtual network rule on stpinecrestdr, the rule cannot be added because the Microsoft.Storage endpoint on snet-app does not apply to a storage account in East US 2. The solution must not use a private endpoint and must keep the change limited to snet-app.
What should you do?
- AReplace the Microsoft.Storage service endpoint on snet-app with the Microsoft.Storage.Global service endpoint, then add the virtual network rule on stpinecrestdr.The regional Microsoft.Storage endpoint provides connectivity only to storage accounts in the same region as the virtual network (and to its paired region for disaster recovery designs; West US pairs with East US, not East US 2). Microsoft.Storage.Global covers storage accounts in any region, and a subnet can hold only one of the two, so the regional endpoint must be replaced.
- BEnable the Microsoft.Storage service endpoint on the GatewaySubnet of VNet-Clinic and add that subnet instead.The GatewaySubnet is not the source of the application traffic, and the regional Microsoft.Storage endpoint on any subnet of a West US network would still not cover a storage account in East US 2.
- CMove stpinecrestdr to the East US region so that it is in the paired region of West US.Storage accounts cannot be moved between regions in place; the account would have to be re-created and its data copied, which changes the disaster recovery design for a problem the cross-region endpoint already solves.
- DAdd the 10.120.3.0/24 range as an IP network rule on stpinecrestdr.IP network rules accept only public IPv4 addresses and ranges; RFC 1918 ranges such as 10.120.3.0/24 are rejected, and traffic over a service endpoint is identified by subnet rather than by IP address.
Why: The regional Microsoft.Storage service endpoint provides connectivity to storage accounts in the same region as the virtual network, with Microsoft's disaster recovery guidance also covering the paired region. West US is paired with East US, so a storage account in East US 2 is out of scope for a West US subnet with the regional endpoint, which is why the virtual network rule is refused. Microsoft.Storage.Global is the cross-region variant and provides connectivity to storage accounts in any region while keeping traffic on the Microsoft backbone; because a subnet can carry only one of the two endpoint types, the regional one is removed and replaced. The deciding constraints are the unpaired destination region, the ban on private endpoints and the requirement to change only snet-app. The trap is assuming that any Microsoft.Storage endpoint is enough; the region relationship decides which endpoint type you need.
Design and implement service endpoints
Pinecrest Health has an Azure SQL logical server named sql-pinecrest-ehr and a virtual network named VNet-Clinic (10.120.0.0/16) with the subnets snet-web (10.120.1.0/24) and snet-db-clients (10.120.2.0/24). Only virtual machines in snet-db-clients should be able to reach the SQL server, and the team plans to use a service endpoint and a virtual network rule on the server.
Where should you enable the Microsoft.Sql service endpoint?
- AOn the subnet snet-db-clients.Service endpoints are a subnet-level setting; enabling Microsoft.Sql on snet-db-clients tags traffic from that subnet so that the virtual network rule on sql-pinecrest-ehr can match it.
- BOn the virtual network VNet-Clinic so that all subnets inherit it.Service endpoints cannot be set at the virtual network level; they are configured per subnet, and enabling it for all subnets would also admit snet-web.
- COn the network interfaces of the virtual machines in snet-db-clients.Network interfaces have no service endpoint setting; the endpoint is a property of the subnet that the interfaces belong to.
- DOn the Networking page of sql-pinecrest-ehr, so that the server advertises the service endpoint to VNet-Clinic.Service endpoints are enabled on the client subnet, not on the target resource. The server side holds only the virtual network rule that references the subnet; there is no service endpoint setting on the logical server.
Why: A service endpoint is configured on a subnet, and only traffic that leaves that subnet toward the chosen service carries the subnet identity. The resource side then needs a matching virtual network rule, which for Azure SQL is created on the logical server and references the subnet. The deciding constraint is that only snet-db-clients may connect, so the endpoint is enabled only on that subnet and not elsewhere. The traps are the wrong levels: there is no virtual network-wide, network-interface or server-side service endpoint setting.