Ops wants a lightweight sidecar-style agent to ship enhanced telemetry from many Lambdas without rewriting business handlers each time. Which Lambda feature fits?
Select an answer to reveal the explanation.
Short Explanation
Picture a quiet sidecar that rides with every delivery truck without rewriting the cargo checklist. Lambda extensions host that cross-cutting telemetry agent outside the business handler. Pasting HTTP clients into every function, gutting handlers for Map states, or silencing logs miss the extension model.
Full Explanation
Ops that want a lightweight sidecar-style agent to ship enhanced telemetry from many Lambdas without rewriting business handlers each time should use Lambda extensions. Extensions run alongside the handler and can subscribe to telemetry lifecycle events, flush logs/metrics/traces, or pull remote config—cross-cutting platform concerns without invading every business repository. Central platform teams supporting dozens of municipal functions gain consistent instrumentation without waiting on each app squad to paste identical boilerplate.
Hard-coding a new telemetry HTTP client into every business function’s main path multiplies maintenance and risks inconsistent field names and sampling. Replacing all handlers with Step Functions Map states that only emit metrics abandons the business compute model the functions exist to run. Turning off CloudWatch Logs so extensions become unnecessary deletes observability instead of improving it.
Exam caveat: extensions add to init duration and have their own failure modes—measure cold-start impact. Prefer AWS-managed or carefully vetted extensions in regulated environments. Extensions complement structured logging in handlers; they do not excuse logging secrets.
Operational check: package a telemetry extension; attach it via layers to pilot functions; verify spans and metrics arrive without handler code changes; measure cold-start delta; and roll out once SLOs and security review hold.