Build a recursive trigger loop and stop it with a concurrency limit

short · 45 min · Objective 5.6

Task

The classic serverless cost incident is a function whose output re-triggers it. Build one deliberately in a contained environment, observe how fast it grows, and then apply the control that actually stops it.

Steps

  1. Configure a function triggered by a file appearing in lab/events/in/, which writes its output to the SAME directory. Add a counter so you can see invocations.
  2. Drop one file in and watch. Record in lab/events/loop.md the invocation count after 30 seconds, and state what would bound it if nothing intervened.
  3. Stop it. Apply a CONCURRENCY LIMIT of two and repeat. Record the invocation rate now, and note that the loop still exists -- it is merely capped.
  4. Fix it properly with a trigger filter: the function writes to lab/events/out/ instead, or the trigger matches only a prefix the output does not use. Confirm one input produces exactly one invocation.
  5. Write in lab/events/loop.md which control PREVENTED the loop and which merely limited the damage, and where a budget alert fits in that ordering.

Verify

grep -Ec '[0-9]+ invocation' lab/events/loop.md
grep -Eci 'concurrency limit' lab/events/loop.md
grep -Eci 'filter|prefix|separate' lab/events/loop.md
grep -Eci 'budget alert' lab/events/loop.md

All four non-zero. The ordering is the point: the trigger filter prevents, the concurrency limit caps, and the budget alert only tells you afterwards.

This is an independent study companion for CompTIA Cloud+ CV0-004 and is not produced by or endorsed by CompTIA.