A bank operates 60 MPLS branches carrying voice that cannot tolerate tunnel overhead or added latency. Security policy requires any-to-any encryption without spoke-to-hub tunnels, and the WAN provider guarantees no packets ever traverse the public internet. Which GET VPN group key design best satisfies low-overhead encryption over trusted private transport?

GET VPN with a group key server is correct because GDOI distributes a common group SA to all 60 members, enabling any-to-any IPsec encryption that preserves the original IP header without GRE or added tunnels, which minimizes overhead and latency for voice while avoiding hub hairpin and operating entirely over trusted private MPLS with no public internet exposure. The DMVPN Phase 3 design with NHRP shortcuts fails the low-overhead requirement because even with dynamic spoke-to-spoke shortcuts it still adds GRE plus IPsec encapsulation and NHRP resolution delay, increasing header size and jitter that voice cannot tolerate. The IPsec VTI hub-and-spoke design fails the topology requirement because spoke-to-spoke traffic must hairpin through the hub for decrypt and re-encrypt, violating the mandate for any-to-any without spoke-to-hub tunnels and adding latency and bottleneck. The internet-based GET VPN design fails the transport requirement because carrying group-encrypted traffic over public internet links violates the guarantee that packets never traverse the public internet and undermines the private-transport assumption behind the design. As an exam caveat, both DMVPN and GET VPN support any-to-any, but only GET VPN avoids tunnels and preserves headers, so focus on overhead and transport wording. As a practical check, verify key server redundancy and GDOI registration, confirm identical transforms and show crypto gdoi status on branches, and measure voice latency, jitter and loss under load.