I started studying AWS because I was already using its services and wanted a better explanation for the choices around them. Getting a task done and understanding why a service fits are different levels of familiarity. The useful part of the certification path was turning names I recognised into questions I could reason through: where traffic goes, what a cache promises, and how much recovery a system actually needs.
Build the missing practice interface
During AI Practitioner preparation, a practice resource had questions but lacked the timed-test and score-tracking experience I wanted. I put the questions into structured JSON, built a local Flask version, then rewrote the frontend as a static single-page app. It gave me a small mobile study tool for the MRT ride to my climbing gym. Seven practice sets became eight options by adding a randomized set drawn from the others.
The app’s engineering was modest, but its form followed the need closely. A local Python interface was enough to start; a static frontend removed the need to run a server when I wanted to practise on my phone. I link the experiment as a study tool, rather than an official AWS resource. The interesting part here is the small change from consuming a resource to building the interface I needed around it.
Tradeoffs made the later study stick
Solutions Architect – Associate pushed me hardest on VPCs, subnets, and routing. I went through the material a second time and worked through difficult scenarios before the pieces clicked. Once the network path made sense, service-selection questions became less isolated: I could place the service inside a system and ask how a request would reach it.
- Developer – Associate gave me a clearer vocabulary for caching. Cache-aside exposes misses and stale reads; write-through adds work to the write path; write-behind introduces a durability gap before persistence.
- Solutions Architect – Professional made recovery time and recovery point explicit requirements. Backup/restore, pilot light, warm standby, and active-active arrangements buy different recovery behavior at different ongoing costs.
- Across both, the useful exercise was explaining which constraint justified the choice instead of selecting the most elaborate architecture.
My published pass announcements cover Cloud Practitioner, AI Practitioner, Solutions Architect – Associate, Developer – Associate, and Solutions Architect – Professional. I treat those five milestones as a record of study. The more transferable output is the habit of stating an assumption and tracing its consequences: what can be stale, what can be lost, how long recovery can take, and what the system costs while waiting for a failure.