Traffic-signal controllers run a real-time operating system with limited security tooling. Which statement best captures the architecture implication?
Select an answer to reveal the explanation.
Short Explanation
Signal controllers are specialized appliances on a stopwatch, not office PCs with a big security agent catalog. Expect constrained tooling and design around isolation. Parking them on staff Wi-Fi is not a firmware strategy.
Full Explanation
Traffic-signal controllers running real-time operating systems are embedded, timing-sensitive platforms with limited CPU, memory, and support for traditional endpoint security agents such as full EDR stacks common on city laptops. Architecture implications include constrained patch and tooling options, specialized availability requirements, and a greater reliance on network isolation, allow-listed engineering access, and integrity of update processes. Security+ embedded/RTOS themes emphasize designing around constraints rather than assuming desktop security controls transplant cleanly.
Claiming RTOS devices support the same full EDR agent stack with no tradeoffs ignores resource and vendor limitations. Asserting embedded controllers never need network isolation because RTOS code cannot be abused is unsafe—firmware and protocol weaknesses exist and have been exploited in industrial and traffic systems. Sharing the staff Wi-Fi SSID to simplify firmware updates places safety-critical controllers on a convenience network with broad user exposure.
Exam caveat: RTOS/embedded answers stress constrained platforms and fewer traditional endpoint options, pushing isolation and specialized management. Operationally, keep signal controllers on dedicated networks, authenticate maintenance sessions, control physical cabinet access, validate firmware integrity before updates, and monitor out-of-profile traffic from cabinets without installing unsupported heavy agents that could disrupt real-time behavior.