Acquia Cloud Pro common mistakes
Acquia Cloud Pro · Understand the traps and how to avoid them.
Treating the Dev, Stage, and Prod environments as if they share a single database and a single set of files, and assuming a config change made in Dev automatically appears in Prod.
Candidates conflate the code repository (shared across environments) with the per-environment services (database, files, search, cache, Varnish) that Acquia provisions separately for each environment.
What to do instead
Memorize the model: one codebase in Git, but each environment has its own database, file system, and search index; code moves via deployment, while content/config/data must be moved explicitly with the documented copy/backup workflows.
Believing that committing and pushing to the default branch instantly changes what production serves, and answering deployment questions as if push equals deploy.
Familiarity with push-to-deploy PaaS products leads candidates to skip the Acquia Cloud task-based deploy step, where code is deployed to an environment from a branch or tag.
What to do instead
State the pipeline explicitly: commit, push to the remote, then run a deploy task to the target environment; production changes only after the deploy to Prod completes (and after any required code switch or tag).
Recommending that hotfixes be committed directly on the production branch or that environments be edited in place, rather than fixing in Dev and redeploying.
Under time pressure, direct-to-production edits feel faster, and candidates forget that Acquia Cloud's model keeps Prod as a deploy target, not an editing surface.
What to do instead
Describe the correct hotfix path: branch from the production tag, fix, test in a lower environment, tag, and deploy to Prod; never edit code on the server or commit straight to the deployed branch.
Assuming Drupal configuration exported in code and configuration stored in the database are interchangeable across environments, and that importing config in one environment propagates it to others.
Candidates blur the split between code (in Git, travels by deploy) and active configuration (in each environment's database, travels only by explicit config import or database copy).
What to do instead
Explain that config sync requires the exported YAML in code plus running the import in each target environment, and that database copies carry active config with them; keep UUIDs and config-split strategy consistent so imports don't conflict.
Claiming that clearing Drupal's cache also clears Varnish or that Varnish caching can be tuned by editing settings.php alone.
Candidates collapse the multiple cache layers (Drupal render/response cache, Varnish reverse proxy, CDN, and per-environment Memcached/Redis) into one, and forget that Varnish is managed at the platform level.
What to do instead
Separate the layers: Drupal cache clear, Varnish purge (via the platform/acquia purge modules or the clear-Varnish action), and CDN purge are distinct; Varnish behavior is controlled through platform configuration and cache-control/purge headers, not just settings.php.
Assuming a search index built in one environment is available in another, or that Solr configuration changes take effect without reindexing.
Candidates treat the search service as shared infrastructure and forget that each environment has its own Solr core/index and that schema/config changes require a reindex.
What to do instead
State that search indexes are per-environment, must be rebuilt after content or config changes, and that Solr config files ship in code but require the index to be cleared and reindexed in each environment.
Describing role and permission management as something done only inside the Drupal UI, ignoring the platform-level roles (e.g., team/application roles controlling SSH, Git, and environment access).
Candidates focus on Drupal's permission system and forget Acquia Cloud has its own access model layered on top, governing who can deploy, use SSH, or access environments.
What to do instead
Distinguish the two layers: Acquia Cloud teams/roles/permissions govern platform actions (deploy, SSH, backups), while Drupal roles govern application content; least-privilege answers must address both.
Storing secrets, API keys, or database credentials in the code repository or in settings.php committed to Git, and treating that as acceptable because the repo is private.
Candidates default to Drupal's settings.php pattern and overlook Acquia's environment-variable and secrets mechanisms and the compliance risk of secrets in version control.
What to do instead
Recommend platform-provided environment variables/secrets and untracked local settings includes; secrets stay out of Git, and credentials are injected per environment.
Diagnosing a production outage by guessing at the application layer without first checking platform-level signals such as the Acquia status page, environment logs (Apache/PHP/Drupal), and recent deploy or config-change history.
Candidates jump to code-level causes and skip the structured triage order that separates platform incidents from application incidents.
What to do instead
Use a triage sequence: confirm platform status, review recent deploys/config changes, inspect logs and error reporting, check resource metrics, then isolate to code, config, or infrastructure before proposing a fix.
Proposing to debug production by enabling verbose error display and devel modules on the live site instead of using logs and a lower environment to reproduce.
Candidates reach for familiar local debugging tools and forget that production error display is a security and stability risk, and that Acquia provides log access and non-production environments for reproduction.
What to do instead
Recommend reproducing in Dev/Stage, reading logs (watchdog, PHP, Apache) on the environment, and keeping production error display off while logging verbosely; only apply verified fixes through the deploy pipeline.