While tuning a city permits portal on App Service, a study guide still pairs “optimize” with Azure Cache for Redis. For Domain 1 autoscaling on this web app, what should the developer implement?
Select an answer to reveal the explanation.
Short Explanation
Domain 1 here is about App Service growing more workers—not bolting on Redis because an old study guide said “optimize.” Autoscale on the plan is the skill. Redis and CDN can help elsewhere, but they are not the App Service autoscale answer.
Full Explanation
While tuning the city permits portal, Domain 1 autoscaling for this App Service web app means configuring App Service plan autoscale rules that adjust instance count from host metrics or schedules. That is the compute scale skill on the outline: grow or shrink workers that run the site when load changes. Redis may appear in older study guides next to the word “optimize,” but for this bank and domain the actionable answer is plan autoscale, not introducing a cache as if it were the scale mechanism.
Treating Azure Cache for Redis as the only scale mechanism for App Service web apps confuses response caching/session offload with horizontal compute scale; Redis does not add App Service instances. Azure CDN compression rules can shrink payload size for static content but do not scale out the plan when dynamic permit workflows saturate workers. Durable Functions orchestration hubs coordinate function workflows; they do not replace App Service instance autoscale for a web app hosting model.
Exam caveat: caching and CDN can still be valid performance tactics in real architectures, yet selecting them here fails the Domains-and-skills mapping this item tests. Operational check: open the App Service plan autoscale settings for the permits portal, define a metric or schedule rule, save it, and verify instance count changes under load or on schedule without relying on Redis as a fake scale control.