Before expanding SOAR across every municipal tool, architects warn about downsides. Which set best lists automation considerations and risks?
Select an answer to reveal the explanation.
Short Explanation
Automation can become a fragile Rube Goldberg machine—pricey, complex, one broken hub, and a pile of debt nobody can support. Weigh that against the speed you gain.
Full Explanation
Before expanding SOAR across every municipal tool, architects correctly flag real automation downsides: complexity of integrations and playbooks, cost of platforms and upkeep, single points of failure if orchestration hubs die, technical debt from brittle custom workflows, and supportability concerns when only one engineer understands the spaghetti. Those considerations and risks must be weighed against speed and consistency gains so the county does not build an unmaintainable Rube Goldberg response fabric.
Asserting that automation removes all risk so considerations never apply is wishful thinking and exam-wrong. Claiming only dashboard color choices matter trivializes architecture risk. Limiting risks to printers running out of paper mocks the actual operational hazards of orchestrated security tooling.
Exam caveat: SY0-701 expects recognition that automation has benefits and tradeoffs—memorize both sides. Mitigations include modular playbooks, redundancy for orchestration, change control, documentation, and keeping manual break-glass procedures.
Operational check: before broad SOAR rollout, inventory integration criticality, estimate licensing and staffing cost, design hub redundancy, require peer-reviewed playbooks, and run a failure drill where the orchestration platform is unavailable to prove municipal responders can still act.