The health department portal must reach a lab results API, but nothing else on that lab network should be reachable from the portal tier. Which firewall posture should automation apply?

When a health-department portal must call a lab results API and nothing else on the lab network should be reachable, automation must encode least privilege in the firewall: allow the portal tier only to the specific lab API host and port (and any required return handling inherent to the stateful firewall). That rule set matches the business need—retrieve lab results—without granting adjacency to lab workstations, file shares, management interfaces, or other systems that happen to share the lab VLAN.

A permit-any rule from the portal subnet to the entire lab VLAN fails because it treats the whole lab network as equivalently trusted and reachable, which contradicts "nothing else should be reachable." Blocking the lab API while opening RDP from the portal to all lab workstations fails twice: it denies the required integration and opens a high-risk interactive administration path that the portal tier should not have. Disabling the firewall during business hours for vendor support fails on concept and compliance: scheduled firewall off periods create predictable attack windows and abandon continuous enforcement that municipal health data environments require.

Exam caveat: least privilege is about sources, destinations, and ports together. Naming the API host without restricting port, or allowing the right port to an entire subnet, still over-permits. Pair network rules with API authentication and encryption; the question asks for the firewall posture automation should apply.

Operational check: from the portal tier, confirm the API port to the designated host succeeds and that probes to other lab addresses or ports fail; review automation/IaC so the change is a narrow allow object, not a subnet-wide permit; and ensure vendor access uses governed jump paths rather than business-hours firewall disablement.