AZ-305 private connectivity questions are usually not asking for a generic networking definition. They are asking whether you can choose the right private access pattern for an Azure PaaS requirement and defend the boundary: resource scope, subnet scope, DNS, hybrid access, public exposure, and authorization.
The exam model is compact: use Private Link with a private endpoint when the scenario needs private IP access to a specific PaaS resource or private reachability from more than one network. Use service endpoints when the scenario is about allowing selected Azure virtual network subnets to reach a supported Azure service over the Azure backbone while keeping public endpoint semantics. Then configure the service-side restrictions separately.
Start With Scope
Private Link changes the shape of access to a specific service resource. A private endpoint is a network interface in a virtual network with a private IP address, and clients reach the service through that private endpoint. That makes it a strong exam answer when the requirement says resource-level isolation, private IP access, cross-network private reachability, or stronger data-exfiltration control.
Service endpoints are different. They extend a virtual network subnet's identity to supported Azure services over a direct Azure backbone route. They are useful when the scenario says selected Azure subnets should be allowed to access a supported service, but the service still uses its public endpoint model. A service endpoint does not give the PaaS resource a private IP address.
Do Not Skip The Closing Controls
Private connectivity is not the same thing as complete public exposure closure. The network path and the public endpoint controls are separate design decisions, and public network access or firewall behavior can be service-specific. The safe AZ-305 answer says to add the private connectivity pattern and then explicitly configure the service's public access restrictions when the requirement demands no public path.
The same discipline applies to service endpoints. Enabling the endpoint on a subnet does not, by itself, restrict the service to that subnet. The service resource still needs network rules or access control lists that allow the intended virtual networks and subnets.
DNS Decides Whether Private Endpoint Traffic Is Really Private
Private endpoints add a DNS dependency. The client should use the normal service name, but from the networks that need private access, that name must resolve to the private endpoint's private IP address. For Azure virtual networks, that usually means private DNS zone linkage. For hybrid clients, the design must also account for DNS forwarding or resolution from the on-premises side.
This is a common exam trap: the private endpoint can exist and the route can exist, but if name resolution still returns a public address, the client may not use the intended private path.
Worked Scenario
A company hosts an application in Azure and needs the app to reach one sensitive PaaS resource without exposing access through the public internet. A separate operations team also needs private access from the corporate network over existing hybrid connectivity.
For AZ-305, the stronger answer is Private Link with a private endpoint. The requirement is resource-scoped, needs private IP access, and includes hybrid clients. The design must include routing from on-premises to the virtual network and DNS resolution that maps the service name to the private endpoint address for both Azure and on-premises clients.
The answer is not complete until public access is handled separately. If the requirement says the public path must be closed, configure the relevant public network access or firewall controls for that service. Private Link changes reachability; it does not replace identity, authorization, RBAC, keys, or data-plane permissions.
Now change the scenario. The app runs only in Azure, and the requirement is simply to let selected subnets reach a supported Azure service over the Azure backbone while denying other network origins at the service. In that case, service endpoints plus service-side network rules can be the better fit. Do not add private endpoint DNS or hybrid access design unless the scenario actually asks for private IP access or cross-network private reachability.
Compact Exam Rules
| Scenario signal | Better exam move |
|---|---|
| Private IP access to one specific PaaS resource | Choose Private Link with a private endpoint. |
| Resource-level isolation or data-exfiltration control is emphasized | Prefer Private Link/private endpoint, then configure public access restrictions as needed. |
| Selected Azure subnets should reach a supported service over the Azure backbone | Use service endpoints plus service-side network rules. |
| On-premises clients need private access over VPN or ExpressRoute | Use Private Link/private endpoint with routing and DNS; do not rely on service endpoints alone. |
| Private endpoint exists but clients resolve a public address | Fix Private DNS zone linkage or hybrid DNS forwarding. |
| The question says authentication or authorization failed | Do not solve it with Private Link alone; network reachability is separate from identity and permissions. |
One major trap: "private" is not one switch. Private endpoint selection, DNS resolution, routing, service-side firewall or public network access settings, and identity authorization are different parts of the architecture answer.
Quick Recap
If the interactive components do not load, remember the decision model: Private Link/private endpoints are for private IP access to a specific PaaS resource, resource-level isolation, hybrid private reachability, and stronger exfiltration control. Service endpoints are for supported Azure services when selected virtual network subnets need Azure-backbone access and service-side network rules can enforce the allowed origins. Public endpoint closure, DNS, and identity permissions are separate checks.
Ready to test this under exam pressure? Take the targeted AZ-305 assessment and look for scenarios where the right answer changes because of resource scope, hybrid access, DNS, or public exposure requirements.