Water-utility workstations in an OT Active Directory OU must receive a Carbon Black Cloud policy automatically. Which mechanism does that?
Select an answer to reveal the explanation.
Short Explanation
Drop a new OT PC in the right AD OU and the sensor group should catch it like a sorted mail slot. Criteria-based Carbon Black Cloud groups assign policy without a click per rebuild.
Full Explanation
Water-utility OT workstations in an Active Directory OU receive Carbon Black Cloud policy automatically when sensor-group criteria match that OU and auto-assign the intended policy. Treat the OU as the civic yard map of OT desks: as soon as a rebuilt workstation joins the domain under that OU, Carbon Black Cloud places it in the matching sensor group and applies prevention without a ticket queue of manual clicks. Manual sensor-by-sensor policy assignment after every image rebuild fails by concept because it does not scale for OT fleets and drifts whenever imaging or domain join order changes; automatic criteria, not console clicks, are the automation mechanism. NSX-T T1 NAT rules named after the OU fail because NAT is an overlay networking construct and never assigns Carbon Black Cloud endpoint policy to enrolled sensors. Workspace ONE Access IdP metadata for the OU fails because Access federation metadata governs SSO, not Carbon Black Cloud sensor-group membership or prevention policy. Exam caveat: endpoint-policy automation for Carbon Black Cloud is sensor-group criteria (including AD OU matching), not NSX NAT naming or Access IdP objects. Operational check: place a test water-utility workstation in the OT OU, confirm Carbon Black Cloud sensor-group membership and policy assignment without manual clicks, review the group criteria after an image rebuild, and document the OU-to-sensor-group mapping in the utility endpoint runbook.