Exercise 2: Why the 20-Minute functionTimeout Doesn't Actually Apply — Possible Solution
====================================================================

The team's own functionTimeout setting controls how long the
function's own code is allowed to run before Azure forcibly restarts
the worker process -- but for an HTTP-triggered function specifically,
there's a real, separate, independent limit that sits in front of
this setting entirely: a 230-second maximum for the function to
respond to any single HTTP request.

This 230-second ceiling isn't part of Azure Functions' own
configuration at all -- it comes from the default idle timeout of the
underlying Azure Load Balancer that routes the HTTP request to the
function in the first place. Because this limit exists at the load
balancer level, genuinely outside the function app's own settings, a
function's own functionTimeout value -- even set to a real 20 minutes
-- cannot override or extend it.

ANSWER: A slow HTTP-triggered request would still fail after roughly
230 seconds, well short of the configured 20-minute functionTimeout,
because the real limiting factor here is the Azure Load Balancer's
own separate, fixed idle timeout, not the function's own timeout
setting. The functionTimeout value genuinely has no effect on this
specific limit at all.

WHY THIS WORKS AS AN ANSWER
------------------------------
This correctly identifies that two genuinely different, independent
limits exist for an HTTP-triggered function, and that the more
restrictive, load-balancer-level one applies regardless of the
function's own configuration -- rather than assuming a single
timeout setting governs everything, which is exactly the trap the
chapter's own warn-box was written to prevent.