Acquia Back End Specialist (D10) study materials
Acquia Back End Specialist (D10) study resources

Acquia Back End Specialist (D10): Acquia Platform and Hosting: Acquia Cloud, Environments, Deployments, and Tooling

Acquia Back End Specialist (D10) · Work through your exam, one topic at a time.

All guide sections

Acquia Platform and Hosting: Acquia Cloud, Environments, Deployments, and Tooling

What the exam expects

Acquia Cloud questions test your mental model of the platform rather than Drupal internals. Know the environment tiers: a Dev environment, one or more Stage environments, and a Prod environment, each with its own database, code branch, and domains. Code moves through a Git-based artifact flow: you push to a branch, and a deployment builds that branch onto the environment's servers. Understand that the codebase is a Composer-managed Drupal project, and that the document root is typically docroot.

Pipelines and tooling

Acquia Cloud pipelines (formerly Cloud Hooks / BLT-era workflows) automate build, test, and deploy steps. Know the distinction between a build artifact and the source repository, and how Composer installs run during the build. Acquia CLI (acli) and the Cloud API let you script environment operations: pulling databases, copying files between environments, running drush commands remotely. Acquia Cloud IDE provides browser-based development. Acquia Site Factory is the multisite management product, distinct from single-site Cloud.

Configuration and data flow

A recurring theme is configuration management across environments. Code deploys do not import configuration automatically unless your pipeline does it; database and files are copied between environments on demand, and copying Prod down to Dev is standard practice for realistic testing. Know that environment-specific settings belong in settings.php overrides or Acquia's environment variables, not in exported config.

Worked rule of thumb

If a question asks how a config change reaches production, the safe answer is: export config locally, commit it with code, deploy the branch, then run drush config:import as part of the deployment. Never edit config directly in Prod.

Traps

  • Assuming a code deploy also moves the database or files.
  • Forgetting that each environment has its own database and domains.
  • Confusing Site Factory multisite management with single-site Cloud environments.
  • Believing settings.php values should be exported as configuration.