Automation in the Enterprise
Scaling beyond one workflow
In an enterprise, individual automations become a portfolio that needs governance. Concepts a candidate must know: ownership (who is accountable for a workflow), access control (who can view, edit, run), audit log (a record of runs and changes), secrets management (credentials stored securely, never hard-coded), environment separation (development versus production), monitoring/alerting (knowing when a run fails), and change management (reviewing and approving updates). Also understand reuse - shared connectors and sub-flows reduce duplication - and cost/rate limits, since high-volume automations can hit API quotas.
Traps to watch for
Enterprise questions test governance instincts. Expect distractors that put credentials directly in a step (wrong - use secrets), that let anyone edit a production workflow (wrong - enforce access control and change review), or that treat a failed run as invisible (wrong - monitoring and alerting are required). Another trap is assuming more automation is always better: a workflow with no owner and no monitoring is a liability, and retiring a stale automation is a valid answer. Watch for questions that confuse audit logs (what happened) with monitoring (alerting you now).
Rule of thumb
Every production automation should answer four questions: Who owns it? Who can change it? How do we know it failed? Where are its secrets? Worked example: a finance team's invoice-routing workflow should run in a production environment separate from testing, store API keys in a secrets store, alert the owner on failure, and log every run for audit. If any of the four is missing, that is the gap the question is looking for.