EMS appliances are constrained devices that rarely change and cannot run a heavyweight config agent. How should rare remote tweaks be performed?
Select an answer to reveal the explanation.
Short Explanation
Some EMS boxes are too small for a live-in agent—agentless SSH is the occasional service call with a toolkit, not a roommate. Rare tweaks fit that model. Heavy agents or internet-exposed admin ports are the wrong fit.
Full Explanation
EMS appliances that are resource-constrained, rarely change, and cannot run a heavyweight config agent should receive rare remote tweaks through agentless SSH sessions. Agentless management uses standard remote shells or APIs from an operator workstation or jump host, applies the small change, and disconnects—without leaving a persistent management agent competing for appliance CPU, memory, or storage. That fits specialized municipal EMS devices where change velocity is low and platform limits are real.
Installing a full desktop management suite that exceeds appliance resources fails the constraint: the tooling itself may destabilize or simply will not install. Publishing appliance admin ports on the open internet with shared passwords fails hard on security—exposed admin with shared credentials is an invitation to compromise life-safety-adjacent infrastructure. Requiring a site visit for every one-line configuration correction forever fails operationally when a secure agentless session can safely perform rare tweaks without a truck roll.
Exam caveat: agentless still requires strong authentication, jump-host controls, logging, and network allowlists; it is not an excuse for internet-exposed SSH. Choose agents for frequent change on capable hosts, agentless SSH for infrequent change on constrained appliances.
Operational check: document which EMS models are agentless-only, perform a controlled SSH change via the jump path with session logging, verify admin interfaces are not publicly reachable, and avoid installing oversized agent suites that exceed device capacity.