AWS Builder Center Article

Build the Practice Engine Behind a Static AWS Exam Room

This article goes deeper into the practice engine behind the demo. It explains how one HTML file can load many exam banks through query strings, why the JSON contract matters, how submit and next behavior becomes a learning loop, and how mobile layout choices change user trust. The focus is practical engineering discipline: simple state, visible feedback, reusable data, and prompts that produce maintainable behavior.

Disclaimer

Purpose: This platform serves as an independent project constructed exclusively for the advancement of educational exploration and dedicated artificial intelligence research. It aims to foster a deeper understanding of modern technology without any external influence. Users can utilize this secure environment to study complex systems, test innovative ideas, and learn safely.

Non-Commercial: There is absolutely no underlying business model associated with this independent project. It is strictly not intended to generate financial revenue, monetary profit, or any tangible commercial value. Our core focus remains purely on academic development, ensuring that access remains completely free from hidden costs, corporate sponsorships, or advertising schemes.

No Guarantees: Because this platform operates as an educational tool utilizing experimental artificial intelligence, generated outputs may occasionally be inaccurate, misleading, or entirely incomplete. All provided content is strictly offered on an as is basis, completely without any express or implied warranties, guarantees of factual correctness, or promises regarding overall reliability whatsoever.


Table of Content

Part 1: Design The Practice Engine Around URL State This section explains how exam, chapter, and question query parameters make every practice state shareable, testable, and easy to debug without a backend or account system.

Part 2: Use One JSON Shape For Many Exams This section explores the reusable exam-bank schema and why consistent fields let one renderer support data, ML, networking, cloud operations, FSI, and AI development practice sets.

Part 3: Make Submit Feedback The Learning Loop This section breaks down the answer-checking pattern: selected answers, sorted correct answers, result text, per-option explanations, and no distracting red or green effects.

Part 4: Treat Mobile Buttons As Product Quality This section shows why larger mobile question, submit, and next buttons matter, and how small responsive changes can make the demo feel usable instead of merely complete.

Part 5: Debug With Contracts, Not Guesswork This section turns common vibe-coding errors into checks: failed fetches, missing JSON files, inconsistent answers, bad query strings, and page states that need predictable fallbacks.


Design The Practice Engine Around URL State

Goal

Make a question screen that can be shared, reloaded, bookmarked, debugged, and opened directly from a marketing page.

Prompt

The prompt said the URL query string should include the exam name, chapter, and question, and the page should go to the related question.

Result

practice-room.html reads exam, chapter, and question from URLSearchParams. It derives the JSON filename, fetches it, finds the requested chapter and question, renders the page, and updates the URL on navigation.

Tips

  • A URL is a product interface, not just browser decoration.
  • Default values should make local testing easy.
  • Use replaceState when navigation should update context without leaving the page.
  • Keep the query parameter names human-readable.
  • Make every card link open a meaningful first question.

The URL contract is the smallest possible routing system. It creates deep links without a router, server, database, or authentication layer.


Use One JSON Shape For Many Exams

Goal

Let many exam topics use the same renderer by enforcing one stable content shape.

Prompt

The prompt repeatedly said to follow aws_certified_data_exam_questions.json as the template when adding new practice sets.

Result

All exam banks expose chapters and questions with options, answers, and explanations. That lets the UI support data, machine learning, networking, cloud operations, FSI trading, generative AI, and AI development banks.

Tips

  • Do not let each content import invent its own schema.
  • Keep answer as an array so single-choice and multi-select use one model.
  • Keep explanations keyed by option letter.
  • Store display titles in JSON so the UI can label itself.
  • Count questions with tooling before claiming scale.

Exam-bank inventory from the folder:

  • aws_ai_development_exam_questions.json: 20 questions in 1 chapter.
  • aws_generative_ai_dev_organization_exam_questions.json: 80 questions in 4 chapters.
  • aws_netowrking_core_exam_questions.json: 98 questions in 2 chapters.
  • aws_fsi_trading_desk_design_exam_questions.json: 680 questions in 34 chapters.
  • aws_certified_cloud_operations_exam_questions.json: 520 questions in 5 chapters.
  • aws_fsi_macro_trading_exam_questions.json: 380 questions in 23 chapters.
  • aws_certified_machine_learning_exam_questions.json: 460 questions in 4 chapters.
  • aws_certified_data_exam_questions.json: 82 questions in 5 chapters.
  • aws_certified_data_exam_questions_v1.json: 82 questions in 5 chapters.

Make Submit Feedback The Learning Loop

Goal

Turn a simple quiz into a learning experience by showing why each option is right or wrong after submission.

Prompt

The prompt asked for submit to show correct and wrong answer explanation and explicitly said no red or green UI effect was needed.

Result

The implementation sorts selected answers and correct answers, compares them, prints the result, prints the correct answer, and then renders one explanation block per option.

Tips

  • Text feedback is enough for a first learning loop.
  • Avoid flashy correctness UI until the explanation quality is strong.
  • Keep selected and correct state visible in the result.
  • Use the same submit path for radio and checkbox questions.
  • Make no-explanation fallbacks obvious so content gaps can be fixed.

This is important for vibe coding because it stops the AI from over-designing. The requested behavior was not a gamified scoreboard. It was a study room. The UI should serve recall and review.


Treat Mobile Buttons As Product Quality

Goal

Make the practice room usable on phones, where many builders will study between meetings, on transit, or during quick review sessions.

Prompt

The prompt asked for mobile layout with the question and answer area on top, the question list below, larger question buttons, and larger submit and next buttons.

Result

The CSS uses media queries to change layout order, increase button hit areas, and keep the question list usable when the screen narrows.

Tips

  • Mobile usability is not a polish pass; it is core behavior.
  • Button size is a learning feature when people study on phones.
  • Ordering content matters more than decoration.
  • Keep the current question highlighted.
  • Use simple grids and flex layouts before reaching for complex components.

A practice product fails if users mis-tap answers. A larger button is not cosmetic; it protects attention.


Debug With Contracts, Not Guesswork

Goal

Make failures explain themselves by validating assumptions at the boundary between HTML, URL, and JSON.

Prompt

The build asked for direct JSON loading by query string and later added many exam filenames. That means typos and missing files are the likely failure mode.

Result

The player catches load failures and shows a clear message asking the user to check the exam query parameter and JSON file.

Tips

  • When fetch fails, show the filename that failed.
  • When a chapter is missing, fall back predictably.
  • When a question is missing, start at the first question.
  • When adding a card, verify the JSON file exists.
  • When adding an exam bank, inspect answer arrays and explanation keys.

The debugging lesson is simple: if the AI creates a link, the next prompt should verify the file behind the link. Vibe coding needs a validation reflex.


Field Note 1: URL state

Background

The practice player needed shareable links that open a specific exam, chapter, and question without server routing.

Goal

Make every learning state addressable from a URL.

Prompt

Use exam, chapter, and question query parameters to go to the related question.

Result

The page reads URLSearchParams, resolves the JSON file, finds the chapter, and highlights the current question.

Tips

  • Use stable parameter names.
  • Default to a known practice set.
  • Update the URL on navigation.
  • Make cards link into real states.
  • Test copy-pasted URLs.

Evidence from the demo

The page reads URLSearchParams, resolves the JSON file, finds the chapter, and highlights the current question. This is the part a reviewer can check directly. The field note should stay connected to that evidence instead of drifting into generic advice about vibe coding.

Review check

For URL state, confirm three things: the background describes a real project pressure, the goal names the intended behavior, and the result points to something visible in the files or browser. If one of those three pieces is missing, rewrite the note before publishing.


Field Note 2: JSON loading

Background

The app loads static JSON files directly from the same folder. That keeps deployment simple but makes filenames important.

Goal

Load many exam banks through one player without bundling or backend code.

Prompt

HTML page load the JSON of URL query string.

Result

The player derives the filename from the exam parameter and fetches it before rendering.

Tips

  • Match card exam names to filenames.
  • Show a helpful fetch error.
  • Keep JSON in the same schema.
  • Avoid hidden transformations.
  • Validate the first question renders.

Evidence from the demo

The player derives the filename from the exam parameter and fetches it before rendering. This is the part a reviewer can check directly. The field note should stay connected to that evidence instead of drifting into generic advice about vibe coding.

Review check

For JSON loading, confirm three things: the background describes a real project pressure, the goal names the intended behavior, and the result points to something visible in the files or browser. If one of those three pieces is missing, rewrite the note before publishing.


Field Note 3: answer checking

Background

Single-choice and multi-select questions both appear in AWS-style practice material.

Goal

Use one answer-checking path for radio buttons and checkboxes.

Prompt

Submit should show correct and wrong answer explanation.

Result

The code collects selected inputs, sorts them, compares them with the sorted answer array, and prints a result.

Tips

  • Store answers as arrays.
  • Sort before comparing.
  • Do not assume one answer.
  • Keep selected state readable.
  • Test a select-two question.

Evidence from the demo

The code collects selected inputs, sorts them, compares them with the sorted answer array, and prints a result. This is the part a reviewer can check directly. The field note should stay connected to that evidence instead of drifting into generic advice about vibe coding.

Review check

For answer checking, confirm three things: the background describes a real project pressure, the goal names the intended behavior, and the result points to something visible in the files or browser. If one of those three pieces is missing, rewrite the note before publishing.


Field Note 4: multi-select logic

Background

A multiple-answer item should not need a separate data model from a single-answer item.

Goal

Let answer count determine input type while preserving the same rendering flow.

Prompt

A multiple-choice item has one key; a select-two item has multiple keys.

Result

The renderer uses radio inputs when the answer array has one value and checkboxes when it has more than one.

Tips

  • Derive UI from data.
  • Avoid duplicate renderers.
  • Keep input names consistent.
  • Compare full answer sets.
  • Mention select-two in question text.

Evidence from the demo

The renderer uses radio inputs when the answer array has one value and checkboxes when it has more than one. This is the part a reviewer can check directly. The field note should stay connected to that evidence instead of drifting into generic advice about vibe coding.

Review check

For multi-select logic, confirm three things: the background describes a real project pressure, the goal names the intended behavior, and the result points to something visible in the files or browser. If one of those three pieces is missing, rewrite the note before publishing.


Field Note 5: explanation rendering

Background

The learning value is in the rationale, not only the score.

Goal

Show feedback for every option after submit.

Prompt

When user clicks submit, show correct and wrong answer explanation without red or green UI effect.

Result

The result box lists selected state, answer state, and explanation text for each option.

Tips

  • Explain distractors.
  • Keep correct answer visible.
  • Use text before color effects.
  • Provide no-explanation fallbacks.
  • Review explanation quality.

Evidence from the demo

The result box lists selected state, answer state, and explanation text for each option. This is the part a reviewer can check directly. The field note should stay connected to that evidence instead of drifting into generic advice about vibe coding.

Review check

For explanation rendering, confirm three things: the background describes a real project pressure, the goal names the intended behavior, and the result points to something visible in the files or browser. If one of those three pieces is missing, rewrite the note before publishing.


Field Note 6: chapter navigation

Background

Large exam banks have multiple chapters and hundreds of questions, so navigation must remain simple.

Goal

Render chapter groups and question buttons from the JSON structure.

Prompt

Left area shows all chapters and questions horizontally.

Result

The question list groups buttons by chapter and highlights the current question.

Tips

  • Generate navigation from data.
  • Keep chapter labels compact.
  • Highlight current state.
  • Reset result when changing questions.
  • Avoid manual button markup.

Evidence from the demo

The question list groups buttons by chapter and highlights the current question. This is the part a reviewer can check directly. The field note should stay connected to that evidence instead of drifting into generic advice about vibe coding.

Review check

For chapter navigation, confirm three things: the background describes a real project pressure, the goal names the intended behavior, and the result points to something visible in the files or browser. If one of those three pieces is missing, rewrite the note before publishing.


Field Note 7: error states

Background

A static player fails mainly when a query string points to a missing JSON file or malformed content.

Goal

Make the failure obvious to the person testing links.

Prompt

Please check exam query parameter and JSON file.

Result

The catch block changes the title, shows the error message, and displays a clear empty-state instruction.

Tips

  • Fail in the UI, not the console only.
  • Name the likely fix.
  • Keep the page usable after failure.
  • Test bad exam values.
  • Do not hide fetch errors.

Evidence from the demo

The catch block changes the title, shows the error message, and displays a clear empty-state instruction. This is the part a reviewer can check directly. The field note should stay connected to that evidence instead of drifting into generic advice about vibe coding.

Review check

For error states, confirm three things: the background describes a real project pressure, the goal names the intended behavior, and the result points to something visible in the files or browser. If one of those three pieces is missing, rewrite the note before publishing.


Field Note 8: data contract reuse

Background

The same renderer supports Data, ML, Networking, Cloud Operations, FSI, Generative AI, and AI Development practice sets.

Goal

Protect reuse by keeping every bank aligned to the same fields.

Prompt

Follow aws_certified_data_exam_questions.json as template.

Result

New banks became content additions rather than code additions.

Tips

  • Use a golden sample.
  • Check answer and explanations fields.
  • Keep chapter arrays consistent.
  • Avoid per-exam UI branches.
  • Count questions after import.

Evidence from the demo

New banks became content additions rather than code additions. This is the part a reviewer can check directly. The field note should stay connected to that evidence instead of drifting into generic advice about vibe coding.

Review check

For data contract reuse, confirm three things: the background describes a real project pressure, the goal names the intended behavior, and the result points to something visible in the files or browser. If one of those three pieces is missing, rewrite the note before publishing.


Field Note 9: result reset

Background

If a learner moves to a new question after submitting, stale feedback can confuse the next answer.

Goal

Clear result state whenever navigation changes.

Prompt

Next should go to next question and show the new question cleanly.

Result

The player hides and clears the result box when moving between questions.

Tips

  • Reset on next.
  • Reset on question-button click.
  • Keep answers unselected after render.
  • Avoid carrying old correctness text.
  • Make state transitions obvious.

Evidence from the demo

The player hides and clears the result box when moving between questions. This is the part a reviewer can check directly. The field note should stay connected to that evidence instead of drifting into generic advice about vibe coding.

Review check

For result reset, confirm three things: the background describes a real project pressure, the goal names the intended behavior, and the result points to something visible in the files or browser. If one of those three pieces is missing, rewrite the note before publishing.


Field Note 10: next behavior

Background

A practice room needs a fast path through questions without forcing users back to the list.

Goal

Advance within a chapter, then move to the first question of the next chapter.

Prompt

Next: go to next question.

Result

The goNext function increments the question index or advances chapter index when the current chapter ends.

Tips

  • Disable next on the final question.
  • Update the query string.
  • Reset feedback.
  • Render after state changes.
  • Test chapter boundaries.

Evidence from the demo

The goNext function increments the question index or advances chapter index when the current chapter ends. This is the part a reviewer can check directly. The field note should stay connected to that evidence instead of drifting into generic advice about vibe coding.

Review check

For next behavior, confirm three things: the background describes a real project pressure, the goal names the intended behavior, and the result points to something visible in the files or browser. If one of those three pieces is missing, rewrite the note before publishing.


Field Note 11: desktop layout

Background

The desktop prompt separated navigation from answering: left for questions, right for the active item.

Goal

Use screen width to reduce cognitive switching for desktop learners.

Prompt

Desktop page layout: left list of questions button area; right question and answer select area.

Result

The page grid gives a stable sidebar and a larger content panel.

Tips

  • Make the sidebar scrollable.
  • Keep content panel focused.
  • Avoid modal navigation.
  • Use predictable columns.
  • Increase desktop text size.

Evidence from the demo

The page grid gives a stable sidebar and a larger content panel. This is the part a reviewer can check directly. The field note should stay connected to that evidence instead of drifting into generic advice about vibe coding.

Review check

For desktop layout, confirm three things: the background describes a real project pressure, the goal names the intended behavior, and the result points to something visible in the files or browser. If one of those three pieces is missing, rewrite the note before publishing.


Field Note 12: mobile layout

Background

On mobile, a sidebar-first layout would force learners past navigation before seeing the question.

Goal

Reorder the page so the current question appears first.

Prompt

Mobile page layout: top question and answer select area, down list of questions button area.

Result

CSS order rules put the right panel above the left panel on smaller screens.

Tips

  • Put the task first.
  • Move navigation below.
  • Increase spacing.
  • Keep buttons large.
  • Test with long questions.

Evidence from the demo

CSS order rules put the right panel above the left panel on smaller screens. This is the part a reviewer can check directly. The field note should stay connected to that evidence instead of drifting into generic advice about vibe coding.

Review check

For mobile layout, confirm three things: the background describes a real project pressure, the goal names the intended behavior, and the result points to something visible in the files or browser. If one of those three pieces is missing, rewrite the note before publishing.


Field Note 13: question button sizing

Background

Tiny numbered buttons are frustrating on phones, especially when a bank has many questions.

Goal

Improve tap accuracy for mobile review sessions.

Prompt

Mobile version: list of question button larger button size.

Result

The mobile media query increases question button width, height, padding, and font size.

Tips

  • Design for thumbs.
  • Avoid dense tap targets.
  • Keep numbers legible.
  • Use wrapping rows.
  • Preserve current highlight.

Evidence from the demo

The mobile media query increases question button width, height, padding, and font size. This is the part a reviewer can check directly. The field note should stay connected to that evidence instead of drifting into generic advice about vibe coding.

Review check

For question button sizing, confirm three things: the background describes a real project pressure, the goal names the intended behavior, and the result points to something visible in the files or browser. If one of those three pieces is missing, rewrite the note before publishing.


Field Note 14: submit and next sizing

Background

Submit and next are the core interaction buttons. If they feel small, the whole app feels unfinished.

Goal

Make primary actions comfortable on mobile.

Prompt

Mobile version: submit, next button larger button size.

Result

The action buttons receive larger min-height, padding, and font size on mobile.

Tips

  • Prioritize action buttons.
  • Use consistent height.
  • Avoid cramped rows.
  • Make disabled state visible.
  • Test one-handed use.

Evidence from the demo

The action buttons receive larger min-height, padding, and font size on mobile. This is the part a reviewer can check directly. The field note should stay connected to that evidence instead of drifting into generic advice about vibe coding.

Review check

For submit and next sizing, confirm three things: the background describes a real project pressure, the goal names the intended behavior, and the result points to something visible in the files or browser. If one of those three pieces is missing, rewrite the note before publishing.


Field Note 15: option rendering

Background

Options need enough spacing for multi-line AWS scenario answers.

Goal

Render each option as a label so clicking text selects the input.

Prompt

Responses are possible answers; options should be similar in length and complexity.

Result

Each option uses a label wrapper with input and text, improving accessibility and click behavior.

Tips

  • Wrap input and text together.
  • Use option letters.
  • Allow long text to wrap.
  • Keep gap consistent.
  • Avoid tiny radio targets.

Evidence from the demo

Each option uses a label wrapper with input and text, improving accessibility and click behavior. This is the part a reviewer can check directly. The field note should stay connected to that evidence instead of drifting into generic advice about vibe coding.

Review check

For option rendering, confirm three things: the background describes a real project pressure, the goal names the intended behavior, and the result points to something visible in the files or browser. If one of those three pieces is missing, rewrite the note before publishing.


Field Note 16: query update

Background

A learner should be able to share the current question after clicking through the app.

Goal

Keep browser URL synchronized with app state.

Prompt

When user clicks a question, go to related question.

Result

The updateQueryString function writes exam, chapter, and question into the current URL.

Tips

  • Update after every navigation.
  • Use replaceState for quiet updates.
  • Keep exam names extension-free.
  • Avoid full reloads.
  • Validate shared links.

Evidence from the demo

The updateQueryString function writes exam, chapter, and question into the current URL. This is the part a reviewer can check directly. The field note should stay connected to that evidence instead of drifting into generic advice about vibe coding.

Review check

For query update, confirm three things: the background describes a real project pressure, the goal names the intended behavior, and the result points to something visible in the files or browser. If one of those three pieces is missing, rewrite the note before publishing.


Field Note 17: no framework decision

Background

The app only needs fetch, DOM creation, state, and a few event listeners.

Goal

Avoid a framework until the interaction model demands it.

Prompt

Create a simple dark-mode page without decoration.

Result

The practice room stays readable as one HTML file.

Tips

  • Use plain JavaScript for small demos.
  • Keep state object tiny.
  • Create DOM from data.
  • Avoid build steps.
  • Refactor only when pain appears.

Evidence from the demo

The practice room stays readable as one HTML file. This is the part a reviewer can check directly. The field note should stay connected to that evidence instead of drifting into generic advice about vibe coding.

Review check

For no framework decision, confirm three things: the background describes a real project pressure, the goal names the intended behavior, and the result points to something visible in the files or browser. If one of those three pieces is missing, rewrite the note before publishing.


Field Note 18: content quality gate

Background

The question guide says distractors must be plausible and rationales must prove the key.

Goal

Make content review part of the engineering workflow.

Prompt

Follow question guide and upgrade practice sets to professional level.

Result

The JSON structure preserves option-level explanations that can be audited later.

Tips

  • Review distractors.
  • Check key uniqueness.
  • Avoid obsolete facts.
  • Use active voice.
  • Keep rationales current.

Evidence from the demo

The JSON structure preserves option-level explanations that can be audited later. This is the part a reviewer can check directly. The field note should stay connected to that evidence instead of drifting into generic advice about vibe coding.

Review check

For content quality gate, confirm three things: the background describes a real project pressure, the goal names the intended behavior, and the result points to something visible in the files or browser. If one of those three pieces is missing, rewrite the note before publishing.


Field Note 19: public link testing

Background

Every landing-page card depends on a matching practice-room URL.

Goal

Treat each card as a test case for the player.

Prompt

Add exam card with link exam_name&chapter=1&question=1.

Result

The library became a set of ready-made deep links into the app.

Tips

  • Click every new card.
  • Check JSON filename spelling.
  • Check first chapter number.
  • Check first question number.
  • Confirm title loads.

Evidence from the demo

The library became a set of ready-made deep links into the app. This is the part a reviewer can check directly. The field note should stay connected to that evidence instead of drifting into generic advice about vibe coding.

Review check

For public link testing, confirm three things: the background describes a real project pressure, the goal names the intended behavior, and the result points to something visible in the files or browser. If one of those three pieces is missing, rewrite the note before publishing.


Field Note 20: learning loop ownership

Background

The practice player owns learning behavior; the landing page owns discovery.

Goal

Keep responsibilities separated so changes stay simple.

Prompt

Use index.html for catalog and practice-room.html for questions.

Result

The system can grow the catalog without touching answer checking, and improve the player without rewriting marketing copy.

Tips

  • Separate discovery from practice.
  • Keep content in JSON.
  • Use links as boundaries.
  • Avoid cross-file coupling.
  • Document who owns each behavior.

Evidence from the demo

The system can grow the catalog without touching answer checking, and improve the player without rewriting marketing copy. This is the part a reviewer can check directly. The field note should stay connected to that evidence instead of drifting into generic advice about vibe coding.

Review check

For learning loop ownership, confirm three things: the background describes a real project pressure, the goal names the intended behavior, and the result points to something visible in the files or browser. If one of those three pieces is missing, rewrite the note before publishing.