On election night, almost all extra traffic is citizen HTTPS to the results website, with little VM-to-VM chatter. Where should the administrator size firewall monitoring and logging for that spike?
Select an answer to reveal the explanation.
Short Explanation
Election night is a crowd at the front doors, not clerks passing notes in the back office. Size logging on the Edge Gateway Firewall that faces that north-south surge.
Full Explanation
On election night, when almost all extra traffic is citizen HTTPS to the results website with little VM-to-VM chatter, size firewall monitoring and logging on the Gateway Firewall that sees the north-south results-web load. The crowd is at the front doors, so Edge Gateway Firewall counters, capacity, and SIEM feeds must be ready for that surge. Sizing only Distributed Firewall Application rules among results-database replicas fails by concept because the spike is inbound citizen north-south, not replica east-west chatter; east-west monitoring alone misses the election-night load plane. Sizing only Carbon Black Cloud sensor prevent events fails because endpoint prevention telemetry does not measure Edge HTTPS capacity or Gateway Firewall deny/allow volume for the published results site. Sizing only Workspace ONE Access device compliance fails because Access posture events are not a substitute for north-south firewall monitoring of anonymous or broad citizen HTTPS to a results VIP. Exam caveat: north-south citizen surges are monitored on Gateway Firewall; do not confuse them with east-west DFW replica traffic, CBC prevent events, or Access compliance dashboards. Operational check: baseline Gateway Firewall CPU, sessions, and log rates before polls close, enable appropriate logging on results VIP rules, confirm SIEM ingestion keeps up, spot-check that Distributed Firewall east-west among replicas stays quiet relative to Edge, and capture the monitoring plan in the elections runbook.