A school-clinic VDI desktop reaches the district EHR as the logged-on nurse, not as a service account. How should that flow be identified for NSX-T controls?
Select an answer to reveal the explanation.
Short Explanation
The nurse is walking to the records room, not a batch job with a service badge. That VDI-to-EHR path is user-driven east-west—Identity Firewall can key off the user, not just a static VM group.
Full Explanation
When a school-clinic VDI desktop reaches the district EHR as the logged-on nurse rather than as a service account, identify the flow as user-driven east-west traffic that is an Identity Firewall candidate, not only a static service-to-service group. The nurse walking to the records room carries a user identity; NSX-T Identity Firewall can key policy off that user in addition to or instead of a blunt VM group. Calling it vMotion kernel traffic because VDI desktops can migrate fails by concept because the EHR access path is guest application traffic from the desktop session, not the VMkernel migration channel used when a VM moves hosts. Calling it north-south Edge traffic merely because EHR is an application fails because application importance does not redefine direction; VDI-to-EHR inside the civic fabric is typically east-west unless the EHR is truly published only beyond the Edge. Treating Carbon Black Cloud sensor-group traffic as a replacement for Distributed Firewall fails because endpoint prevention groups do not substitute for NSX-T identity-aware distributed firewall decisions on east-west paths. Exam caveat: interactive user-to-app east-west flows are Identity Firewall candidates; do not misfile them as vMotion, automatic north-south, or Carbon Black Cloud-only controls. Operational check: verify Guest Introspection or identity prerequisites, map the nurse AD group into Identity Firewall, test VDI-to-EHR allow for that user and deny for an unauthorized user, confirm static-only VM groups alone are insufficient for the requirement, and log identity hits to the district SIEM.