Challenge 2: Why the First Morning Visitor Always Sees a Slow Page —
Solution Walkthrough

What's actually happening:

By default, an Application Pool's worker process is shut down
entirely after 20 minutes with no incoming requests (the idleTimeout
default). Overnight, with no employees using the internal site, this
threshold is crossed easily, and the worker process shuts down
completely to free up server resources. The first employee to open
the site each morning sends the request that triggers a full cold
start of the worker process -- application initialization and, for a
.NET application, JIT compilation of the code paths that first
request touches -- which is genuinely slow compared to a normal
request served by an already-running, already-warmed-up process. Every
subsequent request that same morning is fast because the worker
process is now already running and warmed up.

What change would fix it:

Setting the Application Pool's startMode to AlwaysRunning (paired with
the Application Initialization module) keeps its worker process
running continuously, even through long idle periods with zero
traffic. This eliminates the idle shutdown-and-cold-start cycle
entirely -- there's no longer a "first request of the day" that pays
a startup penalty, at the cost of the worker process consuming a
small amount of server resources even while genuinely idle overnight.

WHY THIS WORKS AS AN ANSWER
------------------------------
This exercise checks that the reader can recognize the idle-timeout/
cold-start pattern from a real-world symptom description (consistently
slow first request, fast afterward) rather than only from the
directive's own name, and knows the specific fix (AlwaysRunning) --
not just that "something about pool settings" is involved.