A university intern’s personal AWS sandbox for learning has different Support needs than a city’s production permitting portal. How should leaders match Support plans?
Select an answer to reveal the explanation.
Short Explanation
Match the plan to the stakes. A hobby sandbox can live on Developer Support; a live city portal should look at Business or higher.
Full Explanation
A university intern's personal AWS sandbox for learning has different Support needs than a city's production permitting portal. Leaders should choose Developer-class Support for sandbox learning when appropriate, and evaluate Business or higher for production civic systems. Matching plan to stakes avoids both overpaying for student sandboxes and under-supporting citizen-facing production outages.
Buying Enterprise Support for every student sandbox while refusing Business Support for production reverses priorities. Using only Basic Support for all production outages because "phone support is unnecessary" ignores civic uptime duties. Trusted Advisor checks are not a paid Support plan that replaces Business and Enterprise—Trusted Advisor check availability expands with Support level, but it is not itself the Support plan substitute. Priority inversion and category errors are the traps.
Exam caveat: Align Support tier to environment criticality. Sandbox → Developer often suffices; production → Business/Enterprise family. Trusted Advisor ≠ Support plan.
Operational check: maintain separate AWS accounts for sandboxes versus production, attach Support plans per account criticality, document who may open production cases, train interns not to test severity-1 processes on sandbox Developer plans expecting TAM response, and review Support spend annually against actual case volume.