A civic Wi-Fi captive portal asks users for an email address before granting Internet. What function does that portal primarily provide?
Select an answer to reveal the explanation.
Short Explanation
You associate first; then the portal is the velvet rope—email, accept terms, then the Internet opens. It is a web gate after join, not a replacement for association, a DNS black hole by design, or proof of WPA3 everywhere.
Full Explanation
A civic Wi-Fi captive portal that asks users for an email address before granting Internet primarily gates network use via a web login or accept page after the client associates. Association and portal onboarding are different layers: the radio joins, then the browser is steered to a policy/login page. Municipal guest designs use portals for AUP acceptance and basic identity collection—not as proof of WPA3-SAE everywhere.
'Replace 802.11 association so radios never need an SSID' fails because portals do not replace 802.11 association so radios never need an SSID. 'Disable all DNS so browsers cannot resolve any hostname' fails because portals do not work by disabling all DNS so browsers cannot resolve any hostname as their sole mechanism description. 'Prove that WPA3-SAE is active on every municipal mesh hop' fails because an email portal does not prove WPA3-SAE is active on every municipal mesh hop.
Exam caveat: legitimate portals and evil-twin portals can look similar—users need validation habits. Operational check: document the city's legitimate guest portal flow, ensure assessors can distinguish it from rogue clones, and test only under RoE. Verify AUP logging meets privacy policy without over-collecting. In municipal wireless operations, record the rationale in the engagement notes so future assessors know which control or technique class was chosen and which failure modes the rejected options would create for city services.