Acquia Back End Specialist (D10) common mistakes
Acquia Back End Specialist (D10) · Understand the traps and how to avoid them.
Treating the routing file's _permission requirement as sufficient and skipping access checks in custom controllers or menu links, then being surprised when a route is reachable by anonymous users.
Candidates assume Drupal's routing layer always enforces access, but routes without an _access/_permission/_role requirement default to open, and controllers that bypass the routing access checker inherit no protection.
What to do instead
For every route, declare an explicit requirement (_permission, _role, _entity_access, or a custom _access_checker) and verify with a test or manual anonymous request; remember the default is deny only when a requirement is present.
Using \Drupal::service() or \Drupal::entityTypeManager() inside a class that could be dependency-injected, then failing questions about testability and service wiring.
Static service calls are the fastest way to get code working during practice, so candidates build the habit and stop recognizing constructor injection patterns in exam scenarios.
What to do instead
Practice writing services with constructor injection plus a services.yml entry, and be able to explain why static calls make unit testing and mocking harder.
Confusing the order and purpose of Drupal's render pipeline stages (build, alter, cache, render) and misidentifying where hook_preprocess_HOOK, hook_theme, and #theme wrappers apply.
Most day-to-day work uses only one or two of these hooks, so the full theme layer model is rarely exercised end to end.
What to do instead
Study the theme system as a chain: theme hook definitions in hook_theme, preprocess functions, template suggestions, and #theme/#markup render arrays; trace one field through each stage.
Assuming a cache is invalidated whenever content is saved, without specifying cache tags, contexts, or max-age on the render array.
Development environments often have caching disabled, so incorrect cacheability metadata appears to work until a production-like cache is enabled.
What to do instead
Attach explicit cache tags (e.g., node:N or the entity list tag), contexts for user/route variance, and max-age; test with the render cache and dynamic page cache enabled.
Writing a hook_update_N or schema change that runs on existing sites but omits the matching hook_schema or config/install defaults needed for fresh installs.
Candidates test updates on an existing database and never run a clean install, so the two paths diverge silently.
What to do instead
For every schema or config change, update both the install-time definition and the update hook, then verify by installing from scratch and by running updates on a copy of an older database.
Misusing the Entity API query vs. the database abstraction layer, or forgetting to add access checks (->accessCheck(TRUE)) on entity queries in Drupal 10.
Older tutorials and Drupal 9 habits predate the mandatory accessCheck requirement, and candidates carry those snippets into D10 answers.
What to do instead
Know that entity queries in D10 require an explicit accessCheck() call and be able to choose between entity queries, the database API, and views for a given task.
Placing a module's services, routes, or config in the wrong directory or naming file incorrectly (e.g., mymodule.routing.yml vs. routing.yml, or config in the module root).
Drupal's discovery is convention-based and silent on failure, so a misplaced file simply does nothing and candidates cannot diagnose why their route or service is missing.
What to do instead
Memorize the canonical module layout: *.info.yml, *.routing.yml, *.services.yml, *.module, *.install, config/install, src/, templates/; verify with drush cr and drush route or the container debug command.
Confusing Acquia Cloud environments (dev, stage, prod) with the code pipeline and assuming a commit to the default branch deploys automatically to production.
Local Drupal workflows (composer, git push) feel like deployment, and candidates conflate the git remote with the Acquia deployment mechanism.
What to do instead
Learn the model: branches map to environments, deploys are explicit actions (via UI, CLI, or pipeline), and production typically requires a tag or a deliberate deploy step; know how Acquia Pipelines and Cloud Hooks differ.
Treating the Acquia Cloud database and file system as shared across environments, or assuming configuration changes in dev automatically reach prod.
Local single-site development gives no intuition for per-environment databases, file storage, and config, and candidates answer as if there were one shared state.
What to do instead
Remember each environment has its own database, files, and config; moving data requires explicit backup/copy operations, and configuration travels via code (config sync) or the config management workflow, not automatically.
Overlooking Acquia-specific performance and security layers (Varnish, the Acquia search service, Cloud Hooks, and the role of the settings files) when answering platform questions.
Candidates study core Drupal caching and settings.php in isolation and do not connect them to Acquia's Varnish, search, and environment-specific settings includes.
What to do instead
Review how Acquia Cloud layers Varnish in front of Drupal, how cache tags and purge interact with it, how Cloud Hooks and environment-specific settings files work, and how Acquia Search replaces core search in hosted setups.