A municipal VPN establishes a session by exchanging secrets with public-key cryptography, then encrypts bulk traffic with a shared session key. Which statement correctly separates those roles?

Municipal VPN designs commonly split cryptographic labor by strength and cost. Asymmetric cryptography supports key exchange and identity-related steps—establishing or authenticating parties and agreeing on fresh session material—because public/private key pairs avoid shipping a long-term shared secret across the wire. Once a shared session key exists, symmetric cryptography encrypts the high-volume packet stream efficiently, delivering confidentiality and integrity for bulk traffic at acceptable CPU cost on city gateways and remote worker endpoints.

Claiming symmetric cryptography alone should perform both key exchange and bulk encryption because one shared key is always safer ignores the bootstrapping problem: distributing that shared key securely at scale is exactly what asymmetric exchange helps solve, and a single static shared key is a high-value long-lived secret. Insisting asymmetric must encrypt every user packet misunderstands performance and common protocol design; shared session keys can and do protect confidentiality when derived and managed correctly. Hashing cannot replace key exchange or bulk encryption: digests verify integrity or support protocols but do not provide reversible confidentiality for tunnel payloads.

Exam caveat: map asymmetric to key exchange/identity and symmetric to bulk session encryption; do not confuse hashing with encryption. Operational check: review VPN cipher suites so handshake uses approved asymmetric mechanisms, session ciphers are modern symmetric algorithms with integrity, perfect forward secrecy is preferred, and city remote-access logs show successful negotiation without fallback to obsolete suites.