A timed-out connector may already have acted
A fictional security playbook enriches an alert and proposes blocking an address. The address belongs to a shared service used by several business applications, and the source alert has not yet been independently validated. An external connector request times out after submission, leaving no success message in the workflow. A retry branch would immediately repeat the action with a more privileged credential, while a separate branch can obtain a remote action identifier and check current state. The organization’s policy requires an appropriate approval for this class of disruptive response. The task is to examine the written playbook design, not execute a connector, contact the service or change a firewall. It asks how authority, uncertainty, retries and business impact should be handled.
1. Why should timeout not automatically trigger a privileged retry?
Read the worked answer
The remote action may already have occurred, and additional privilege does not resolve uncertain state or missing authorization. Reconcile the remote result and understand idempotency before repeating an effect.
2. Which checks are needed before any disruptive response?
Read the worked answer
Validate the indicator, asset/business context and actual approval conditions; assess shared-service impact, scope, rollback/recovery and logging. A connector’s presence is not unlimited authority to block its target.