A city water-utility OT network has controllers with tiny CPU and memory budgets that cannot host endpoint agents. How should the SOC choose monitoring coverage for those devices?

Agentless monitoring is the practical choice for resource-constrained water-utility OT controllers that cannot host heavy endpoint agents. Network sensors on SPAN/TAP ports, remote protocol checks, passive asset discovery, and zone-boundary logging observe PLC and HMI behavior without taxing tiny CPU and memory budgets or violating vendor support constraints. Reserve full agents for capable hosts such as engineering workstations and historians while still giving the municipal SOC proportionate visibility into the OT network. That agent-versus-agentless decision matches Security+ guidance on selecting monitoring coverage by platform capability.

Forcing antivirus agents onto every PLC risks instability, failed control processes, or unsupported configurations on devices that lack capacity. Skipping monitoring because OT is “air-gapped on paper” ignores jump hosts, vendor maintenance links, and policy drift that routinely pierce assumed air gaps in civic utilities. Mirroring all OT traffic to the mayor’s laptop is neither a secure architecture nor an operationally sound monitoring design—it concentrates sensitive industrial data on an inappropriate endpoint.

Exam caveat: choosing agentless methods is a deployment constraint decision, not an excuse for zero monitoring. OT programs often emphasize protocol-aware anomaly detection plus strict segmentation and jump-host controls alongside any host telemetry you can safely collect.

Operational check: place industrial sensors at OT zone boundaries, baseline normal control-plane traffic, alert on unexpected engineering protocols sourced from IT, deploy agents only where vendors certify them, and maintain a coverage map the SOC can defend in audit.