DevOps & Deployment Interview Questions

1. Why use Composer with WordPress?

Answer: Composer is a PHP dependency manager.

It allows you to manage WordPress Core, Plugins, and Themes as dependencies (packages).
It ensures all developers and servers are running the exact same versions (via `composer.lock`).
It enables PSR-4 autoloading.
It keeps the git repository clean (you don't commit core or vendor files).

2. Explain the concept of "Immutable Infrastructure" or "Stateless" WordPress.

Answer: In a stateless setup (like AWS Fargate or Kubernetes), the server container can be destroyed and replaced at any time without losing data.

Code: Baked into the Docker image. Cannot be changed at runtime (no plugin updates via WP Admin).
Media: Offloaded to S3 (since local disk is ephemeral).
Database: External RDS (MySQL/Postgres) service.
Logs: Streamed to CloudWatch/Datadog.

3. How do you handle database changes (migrations) in a CI/CD pipeline?

Answer: Database sync is the hardest part of WP deployment.

Code First: We deploy code, not database dumps.
Update Scripts: Use `wp-cli` scripts to run updates post-deploy (e.g., `wp core update-db`, `wp plugin update`).
Content Freeze: For major migrations, freeze editing on Prod, pull DB to Staging, merge, push back (rare and risky).
Ideally: Content flows Down (Prod -> Dev), Code flows Up (Dev -> Prod).

4. What is Bedrock?

Answer: Bedrock is a modern WordPress boilerplate by Roots.io.

Folder structure improved (Web root separated from config).
Dependency management with Composer.
Environment variables (`.env`) for configuration (DB credentials, keys).
Security improvements (non-root web folder).

5. How do you offload media to S3?

Answer: Using a plugin like WP Offload Media or S3-Uploads.

When an image is uploaded, the plugin sends it to an AWS S3 bucket.
It rewrites the URL in the database to point to the S3 (or CDN) URL.
This removes the dependency on local server storage, enabling auto-scaling.

6. What is WP-CLI and how do you use it for automation?

Answer: WP-CLI is the command-line interface for WordPress. It allows you to perform actions without a web browser.

Automation: You can script complex tasks like creating users, installing plugins, regenerating thumbnails, or searching/replacing database strings.
CI/CD: It is essential for deployment scripts (e.g., `wp core update-db`, `wp cache flush`).

7. Explain the difference between a Reverse Proxy and a Load Balancer in a WP context.

Answer:

Load Balancer (e.g., AWS ALB): Distributes incoming traffic across multiple WordPress application servers to ensure high availability and scalability.
Reverse Proxy (e.g., Nginx, Varnish): Sits in front of the web server. It handles caching (serving static HTML to anonymous users), SSL termination, and compression, reducing the load on PHP/Database.

8. How do you secure a WordPress installation at the server level?

Answer:

File Permissions: Ensure web server can only write to `wp-content/uploads`. Core files should be read-only.
Firewall (WAF): Use Cloudflare or AWS WAF to block SQL injection and XSS attacks before they reach the server.
Disable PHP Execution: Prevent PHP execution in the `uploads` directory.
Fail2Ban: Ban IPs that repeatedly fail login attempts.

9. What is Object Caching and why is it important?

Answer: Object Caching stores the results of complex database queries in memory (Redis or Memcached) so they don't need to be computed again.

WordPress has a built-in Object Cache class, but it is non-persistent by default. Using a persistent backend like Redis drastically reduces database load for dynamic pages.

10. How do you debug a "White Screen of Death" in production without showing errors to users?

Answer:

Check the server error logs (Nginx/Apache/PHP-FPM logs).
Enable `WP_DEBUG` and `WP_DEBUG_LOG` in `wp-config.php`, but keep `WP_DEBUG_DISPLAY` set to `false`. This writes errors to `wp-content/debug.log` instead of the screen.
Use a monitoring tool like New Relic or Sentry to capture the stack trace.