A transit authority compares standing up staging and production environments in hours versus weeks of racking servers. Which AWS Cloud benefit is illustrated?
Select an answer to reveal the explanation.
Short Explanation
Staging and prod in hours beats weeks of unboxing servers. That is speed of deployment—spinning environments when you need them instead of waiting on freight. Transit wins when the clock, not the pallet, drives the timeline.
Full Explanation
Speed of deployment is illustrated when a transit authority can stand up staging and production environments in hours on AWS instead of weeks of racking servers in depots. On-demand provisioning from cloud infrastructure removes shipping lead times and physical install cycles from the critical path, so test and production paths for rider-facing systems appear when operations needs them—not when crates arrive.
Slower change because every environment still waits on shipping lead times describes the on-premises constraint the cloud benefit removes, not the benefit itself. Mandatory identical physical racks in every bus depot before testing starts reintroduces facilities CapEx and timeline friction for what should be software environments. High availability defined only as buying two identical unused servers for a closet confuses HA (failure continuity) with environment provisioning speed and still burns capital on idle iron.
Exam caveat: CLF-C02 treats speed of deployment as a core cloud benefit distinct from high availability and elasticity; when the stem contrasts hours versus weeks of racking, choose deployment speed. Operational check: time creation of a staging stack with infrastructure as code in a transit AWS account, compare that clock time to the last depot racking project, and confirm production promotion does not wait on hardware POs.