Deployment Workflow and Code Management
Acquia Cloud deployments are branch-based and Git-driven. Each environment tracks a branch (commonly master/main for Prod, stage, dev), and a deploy moves the branch tip's code artifact onto that environment's servers. Understand the pipeline: commit to a branch → build artifact (Acquia Pipelines or a CI tool) → deploy to an environment. A frequent trap is conflating code deployment with database/file synchronization-deploying code never moves content or data.
Know the three ways code changes reach an environment: deploying an existing branch, switching an environment to a different branch, and creating an on-demand environment from a branch. Also know what a deploy does not do: it does not run database updates automatically (you run drush updb or equivalent), does not clear Varnish unless configured, and does not change config unless config is in code (Drupal 8+).
Worked example: a developer merges a feature into stage, deploys, and the site shows old content. The code is current; the database still holds the old config or content. The fix is to import config (drush cim) or sync the database-not to redeploy. Questions often phrase this as "deploy succeeded but change is not visible."
Traps to watch: whether a deploy triggers a build hook (it can, via Pipelines or Cloud Hooks), whether tags can be deployed (yes, as refs), and whether a hotfix should go to Prod directly (prefer branch → deploy, then merge back). Also expect questions on Cloud Hooks (post-code-deploy, post-db-copy, post-files-copy) for automating steps after events.