Transit vendors need weekend access to a fare API for a cutover. How should the administrator manage that allow?
Select an answer to reveal the explanation.
Short Explanation
Weekend vendor access is a visitor badge that expires Monday, not a master key left under the mat. Use a time-based Distributed Firewall rule, not a forever any-any.
Full Explanation
Transit vendors needing weekend access to a fare API for a cutover should receive a time-based Distributed Firewall rule with an expiry rather than a permanent any-any. Treat the weekend cutover as a temporary vendor badge that automatically expires Monday so the fare API does not keep an open permanent hallway. Creating a forever any-any Emergency rule and reminding staff to delete it someday fails by concept because permanent Emergency any-any is unmanaged privilege that routinely outlives the cutover; time-based expiry is the operational control. Disabling Gateway Firewall until Monday fails because that removes north-south enforcement for all published services, not a scoped vendor allow to the fare API. Adding vendors to the vMotion VMkernel port group fails because vMotion networking is a cluster data-plane construct and does not authorize application access to a fare API. Exam caveat: NSX-T time-based firewall rules publish temporary access that expires automatically; permanent Emergency any-any, Gateway Firewall disable, and VMkernel membership are not temporary vendor allows. Operational check: publish a time-scoped Distributed Firewall allow for the vendor group to the fare API, confirm hits during the weekend window, verify the rule expires, and document the temporary access in the transit change ticket.