Vertex Macro | Financial Cloud Cloud · Builder Articles
Build the Practice Engine Behind a Static AWS Exam Room
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.