A credit-union reviewer asks for “encryption on the peering” between two Azure regions. How should the security engineer respond?
Select an answer to reveal the explanation.
Short Explanation
Peering isn’t a DIY IPsec tunnel—it rides Microsoft’s private backbone. Need crypto you control? Look at VPN or app TLS, not a mythical peering encryption switch.
Full Explanation
VNet peering connects VNets over the Microsoft backbone; it is private relative to the public Internet but is not customer-configured IPsec between the peered VNets. When a credit-union reviewer asks for “encryption on the peering,” state that peering traffic stays on the Microsoft backbone and is not an IPsec tunnel—if network-layer encryption is required, use VPN gateway tunnels or rely on application TLS, not a mythical peering IPsec checkbox.
Enabling a peering IPsec checkbox with customer-managed keys fails because that is not how VNet peering is secured. Disabling peering and forcing inter-region traffic onto the public Internet with NSG allows worsens posture. Converting both VNets to ExpressRoute private peering solely to add MACsec on the peering link confuses ExpressRoute Direct MACsec with VNet peering.
Exam caveat: distinguish platform backbone privacy from customer-managed encryption such as VPN, MACsec, or TLS. Operational check: document the trust boundary for peering, implement VPN or TLS if policy requires customer-controlled crypto, and update the reviewer’s checklist language accordingly. 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.