CloudPrep, Cloud-Cert Practice With Nothing to Keep Running

The stakes

I learn by doing, not by reading, and cloud certifications are a mountain of reading. What I needed was practice: questions, repetition, honest feedback. The tools offering it were somehow worse than the documentation. The ones I tried were cluttered, confusing to navigate, and heavy with ads, or they charged a subscription for material that is, strangely, already free: communities maintain open-source repositories of these questions, corrected and versioned in public.

So I did what any sane person would do about it: I set out to do better. And better had a precise shape, because I was building for an audience of one. It had to fit my size, something one person could build and keep running forever without it asking for attention, and it had to fit how I study: drilling that survives a flight or a dead connection, with no login standing between me and ten minutes of practice. None of that requires an account. None of it requires a server. The project became an almost architectural question: how much product can you ship with zero infrastructure to operate, and nothing about the user to protect because nothing is collected?

The cheapest infrastructure to operate is the infrastructure that does not exist.

The move

Delete the backend. Not “make it serverless”, not “keep it small”: remove the runtime entirely. An app built to one person’s size has to cost that person nothing to keep alive. Every piece of work that a conventional build would do per-request happens exactly once, at build time. A scraper pulls the question banks from their open-source repositories, a parser normalises and validates them into a single JSON dataset, and the app ships that dataset as a static asset alongside its own code.

What a conventional app keeps in a user table, CloudPrep keeps on the device. Stats, notes, and progress live in the browser’s own storage, which means privacy is not a policy the user has to trust; it is a property of the architecture. There is no server to breach and no account to leak, because there is no server and there are no accounts.

What shipped

A Nuxt 4 app spanning certifications across Azure, AWS, Google Cloud, and Databricks, currently built on the Ditectrev collections. Study mode gives untimed practice with instant feedback; spaced-repetition flashcards drill the same banks; IndexedDB and localStorage keep stats, notes, and progress on the device. An installable PWA makes it all work offline, and the whole thing deploys to Cloudflare Pages. Timed mock exams and progress analytics are the pieces still coming together.

The stack, and why

A static dataset, rather than a database and an API. The deciding observation was about change: question banks change when the upstream repositories change, which is occasionally, not per request. A database and API layer would spend its whole life serving identical bytes and waiting to be patched. Compiling to a validated static dataset moves all of that work to build time, where failures are visible in CI instead of in production. Updating the catalogue is re-running a build, not migrating a database.

On-device storage, rather than user accounts. The conventional login-plus-user-table design earns its complexity when data must follow the user across devices or feed a service. Exam prep is personal and short-lived; the progress matters for weeks, on one or two devices the user already holds. IndexedDB and localStorage carry that fine, and what remains is structural privacy: no password to reuse, no email to market to, no table of users to defend.

Nuxt, rather than a heavier app framework. The app is a catalogue, a quiz flow, and a flashcard loop: routed pages sharing state and components, which is exactly the shape a Vue meta-framework handles well. Static generation was a first-class output rather than an afterthought, which is what the whole architecture stands on.

What it changed

• Thousands of questions, drillable offline, with no account and nothing phoning home
• Zero runtime cost and zero operational burden, permanently, by construction
• Progress and notes belong to the device, so privacy is structural, not a policy
• New question banks arrive by re-running a build, not by migrating a database