Acquia Cloud Pro cheat sheet

Each environment (dev, stage, prod) runs on separate infrastructure with its own load balancers, web servers, and database servers.

The production environment typically has multiple web servers behind a load balancer; non-production environments usually have a single web server.

Code flows from dev to stage to prod via branches (e.g., master, stage, prod) and deployment; content and configuration are not automatically synchronized.

Acquia Cloud uses a distributed file system for the sites/default/files directory across web servers; the database is not part of this file system.

Environments can be resized independently; production can have additional servers or higher memory/CPU.

The platform provides Git repositories per application; each environment has a branch that can be deployed.

Acquia Cloud supports multiple applications per subscription, each with its own codebase and environments.

The database is a single MySQL instance per environment (or clustered for high availability in production), not distributed across web servers.

Deployment is triggered via the Acquia Cloud UI, CLI (acli), or API; it deploys a specific branch or tag to an environment.

Code deployments do not automatically run database updates or configuration imports; these must be part of the deployment process or run manually.

Acquia Cloud supports automated deployment via pipelines (e.g., Acquia Pipelines) using a YAML configuration file.

Deployments can be rolled back to a previous codebase using the UI or CLI, but database rollbacks require restoring a backup.

Git branching model: typically master for dev, stage for staging, prod for production; code is merged and pushed to trigger deployments.

Deployment hooks (post-deploy scripts) can be used to run commands like drush updatedb or cache clears.

Code is deployed to all web servers in the environment; file system changes are not deployed (except via file sync).

Acquia Cloud supports hotfixes by deploying a branch with a fix, but best practice is to merge back to the mainline.

Drupal configuration is stored in the database by default; use the Configuration Management system to export/import YAML files.

Environment parity is maintained by keeping configuration in code and importing it across environments, not by copying databases.

Acquia Cloud provides a configuration sync feature (via UI or CLI) to copy configuration from one environment to another.

Use drush config-export and drush config-import to move configuration; ensure that configuration is not overridden in settings.php.

Sensitive configuration (e.g., API keys) should be stored in environment-specific settings files or environment variables, not in exported configuration.

Acquia Cloud supports environment-specific settings via settings.php inclusion based on environment variables (e.g., AH_SITE_ENVIRONMENT).

Database copies between environments can cause configuration overrides; always export configuration from the source and import to target.

Use the config_split module to manage environment-specific configuration (e.g., enabling devel in dev only).

Acquia Cloud provides Varnish caching in front of web servers for anonymous traffic; cache can be purged via tags or entire cache.

Drupal's internal cache is stored in the database by default; use memcache or Redis for better performance (Acquia supports both).

Acquia Search is a hosted Apache Solr service; it requires configuration of an index and can be used for search pages and views.

Enable page caching and block caching in Drupal; use the purge module to clear Varnish when content changes.

Use CDN (Acquia CDN) for static assets to offload traffic from the origin.

Database performance can be improved by enabling query caching, optimizing indexes, and using InnoDB.

Acquia Cloud provides New Relic for performance monitoring; use it to identify slow queries and bottlenecks.

Caching layers: Varnish (page cache), memcache/Redis (Drupal cache), and CDN (static files). Each must be purged appropriately.

Acquia Cloud provides role-based access control (RBAC) with roles like Administrator, Team Lead, Developer, and Viewer.

SSH access is controlled via public key authentication; users must add their SSH keys to their Acquia Cloud account.

Acquia Cloud is compliant with SOC 2, HIPAA, and GDPR; ensure that your application configures appropriate settings for compliance.

Use HTTPS with SSL/TLS certificates; Acquia provides free Let's Encrypt certificates or custom certificates.

Security updates for Drupal core and contributed modules should be applied promptly; Acquia provides security notifications.

Acquia Cloud has a web application firewall (WAF) available as an add-on for additional protection.

Access to the database can be restricted via IP whitelisting in the Acquia Cloud UI.

Audit logs are available for account and environment activities; monitor them for suspicious activity.

Acquia Cloud provides logging via the UI (available logs: web server, PHP, database, Varnish) and via the CLI (acli).

Use New Relic for application performance monitoring; it is preconfigured for Acquia Cloud environments.

Acquia Cloud sends alerts for environment issues (e.g., high load, disk space) to configured email addresses.

Troubleshoot 500 errors by checking PHP error logs and Drupal watchdog logs; use drush ws to view recent logs.

For performance issues, check Varnish hit rate, database slow query log, and New Relic transaction traces.

Incident response: identify the issue, mitigate (e.g., rollback, scale up), communicate, and conduct a post-mortem.

Use the Acquia Cloud status page and support tickets for platform-level incidents.

Backups are taken automatically; you can restore from backups via the UI or CLI for databases and files.