A botanical-garden subscription in another Microsoft Entra tenant needs the lock-scheduling API exposed by a Private Link service. What consumer path should the security engineer describe?
Select an answer to reveal the explanation.
Short Explanation
Other tenant, same API: consumer spins a Private Endpoint at your Private Link service and waits for the nod. No mandatory peering, ExpressRoute, or S2S just to consume PLS.
Full Explanation
Cross-tenant consumers create a Private Endpoint to the Private Link service alias or resource and wait for approval—no guest-network VNet peering is required to consume a Private Link service. That is the path for a botanical-garden subscription in another Entra tenant reaching the lock-scheduling API.
Creating an ExpressRoute circuit from the garden tenant directly into the PLS alias fails as the consumer path. Claiming site-to-site VPN is the only supported cross-tenant PLS consumption method fails. Claiming VNets must peer across tenants first because Private Endpoints cannot target a PLS without peering fails—Private Link is specifically for private connectivity without those classic hybrid/peer requirements.
Exam caveat: Private Link works across subscriptions and tenants with approval workflows. Operational check: share the PLS alias securely, create the PE in the garden tenant, approve on the provider side, validate DNS and connectivity, and skip unnecessary peering. In municipal Azure estates, document the decision in the change record, validate with a nonproduction rehearsal, and confirm monitoring still pages the on-call operator when the control fails closed during an incident drill.