Acquia Site Builder D10 common mistakes
Acquia Site Builder D10 · Understand the traps and how to avoid them.
Building a content type by hand in the UI and leaving its field storage, view modes, and form display settings undocumented, then being unable to explain how the structure would be exported and re-imported.
Candidates learn the click path for adding fields but skip the fact that Drupal 10 stores content structure as exported YAML configuration; the exam asks about configuration management implications of structural choices.
What to do instead
For every structure you create, state which configuration objects result (node type, field storage, field instance, form display, view display) and practise exporting them to YAML and reading the resulting files so you can describe what travels between environments.
Using a taxonomy vocabulary for a small closed set of values that an author should never extend, then having to lock down permissions after the fact.
Both taxonomy and list fields can hold categories, so candidates pick the one they used most recently rather than reasoning about who controls the allowed values.
What to do instead
Choose a list field when the allowed values are fixed by the site builder and belong in configuration; choose taxonomy when editors must add terms at runtime and terms need their own pages or hierarchy. Verify by asking whether adding a value should require a config deployment.
Configuring a view that lists content but forgetting to set a contextual filter or relationship correctly, producing a page that shows all content instead of the related content.
Views configuration is layered (filter, contextual filter, relationship, argument validation) and candidates test only with the default preview rather than with real argument values.
What to do instead
Always test a view by supplying the argument in the preview and by visiting the live path with a real value and an invalid value; confirm the 'no results' behaviour and the validation fallback are what you intend.
Placing blocks in a theme's region and expecting the placement to behave the same across themes, then discovering the block is missing after a theme change.
Block placement is stored per theme in Drupal 10, so candidates who build only in one theme assume placement is global.
What to do instead
Remember block configuration is theme-specific; when a site uses multiple themes, verify and configure placement for each theme, and prefer a default theme plus an admin theme only when you have confirmed the block appears where expected.
Relying on the default front page path setting while also creating a view or node that should be the homepage, resulting in conflicting or stale homepage behaviour.
Several mechanisms can control the front page (the site information setting, a node, or a view page display), and candidates configure one without checking whether another overrides it.
What to do instead
Decide on a single source for the front page, set the default front page path to match it exactly, and clear caches to confirm which mechanism is actually serving the page.
Editing configuration directly in the production database or UI after the site has a configuration management workflow, causing the next import to overwrite or conflict with the change.
Candidates treat the UI as the source of truth because it is where they learned to build, without accounting for the exported configuration being authoritative once a workflow exists.
What to do instead
Treat the exported YAML as the source of truth: make changes in a development environment, export, review the diff, and import. Never hand-edit production config outside that cycle.
Importing configuration without checking the diff first, so that a full import silently deletes content types, fields, or views that exist only in the target environment.
Configuration import is a synchronisation that removes configuration not present in the imported set; candidates assume it is additive.
What to do instead
Before importing, run a diff of active versus staged configuration and read every removal. Confirm that any configuration present only in the target is intentionally being deleted, and take a database backup first.
Assuming content (nodes, taxonomy terms, users) travels with configuration exports between environments.
The word 'export' suggests everything moves, but configuration management handles only configuration entities, not content entities.
What to do instead
Separate the two concerns explicitly: use configuration export/import for structure and settings, and a content migration, deploy hook, or manual recreation for content. State this distinction whenever asked how to move a site between environments.
Leaving UUID or dependency mismatches unresolved and expecting the import to succeed, then being surprised by errors about missing dependencies.
Configuration entities reference each other by UUID and dependency; candidates edit YAML by hand or copy files between sites without preserving those references.
What to do instead
Avoid hand-editing exported UUIDs. If a dependency is missing, export it from the source environment as well, and resolve dependency errors by importing in dependency order rather than by deleting the reference.
Forgetting that some settings are stored as state or in settings.php rather than as exportable configuration, and expecting them to move with a config import.
Candidates treat all site behaviour as configuration, but things like the last cron run, some caches, and environment-specific values live in state or settings.php.
What to do instead
Classify each setting before relying on export: if it is in the configuration system it exports; if it is state it does not; if it is in settings.php it is environment-specific and must be set per environment. Document which category each setting falls into.