A canal reviewer treats ExpressRoute private peering as encrypted because the path is private. What should the security engineer state first?
Select an answer to reveal the explanation.
Short Explanation
Private path ≠ secret handshake. ExpressRoute isn’t encrypted by default—privacy of the pipe isn’t confidentiality. Add MACsec, IPsec overlay, or app TLS when the auditor wants crypto.
Full Explanation
ExpressRoute provides a private connectivity path but does not encrypt customer payloads by default. Path privacy is not confidentiality. When a canal reviewer treats ExpressRoute private peering as encrypted because the path is private, state first that ExpressRoute traffic is not encrypted by default—add MACsec on ExpressRoute Direct where applicable, an IPsec overlay, or application TLS as policy requires.
Claiming private peering automatically enables MACsec on every provider-managed circuit without configuration fails. Claiming ExpressRoute always includes IPsec at Layer 3 whenever FastPath is enabled fails—FastPath is about performance paths, not automatic IPsec. Claiming NSG service tags on the gateway subnet encrypt ExpressRoute frames end to end fails by concept.
Exam caveat: private ≠ encrypted is a classic AZ-500 networking security distinction. Operational check: document the encryption gap, select MACsec, VPN overlay, or TLS per data classification, implement it, and update the reviewer’s architecture diagram. 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.