Site Studio Fundamentals
Site Studio is Acquia's low-code page-building layer that sits on top of Drupal. The exam expects you to know the conceptual model before you touch a UI. At the center are components: reusable, config-driven UI elements. Components are built from elements (the structural building blocks that map to HTML tags) and styles (CSS properties exposed as form controls). Components are grouped into component groups for organization. Templates define where content regions appear on a page, and layouts (canvas layouts) let builders drag components into slots. Style guides hold the design tokens and reusable style definitions that components consume.
A key mental model: Site Studio stores its configuration as exported config (YAML) that must be synced between environments. The Site Studio Sync process packages components, templates, style guides, and other artifacts into a package that is imported on the target environment. A frequent trap is confusing content (nodes, pages) with configuration (components, templates). Content is authored in Drupal; the design system is configuration. Another trap: assuming a component change automatically propagates to every environment - it does not until you sync.
Worked rule of thumb
When a question asks "what must happen before a component edited in dev appears in production," the answer chain is: save the component in dev, run the Site Studio export/sync to generate the package, then import that package in production. Editing the component alone changes only the current environment's config.
Watch for questions that blur elements vs. styles vs. components. Elements are the structural HTML layer; styles are the CSS layer; components are the assembled, reusable unit that combines them and appears in the builder.