Acquia Site Factory Pro flashcards

32 cards. Read the term and the definition here. The deck at the top of this page is optional.

Acquia Site Factory

A multisite management platform built on Acquia Cloud that lets one shared codebase run many Drupal sites, each with its own database, domain, and configuration.

Factory management console

The central interface for creating, cloning, deleting, and governing sites across the factory; it is separate from any individual Drupal site's administrative interface.

Site group

A logical partition of sites in Site Factory used to scope delegated administration, bulk operations, and access; a site can belong to a group.

Shared codebase

A single deployed code repository used by all sites in a Site Factory factory; code changes therefore affect every site that uses that codebase.

Default domain

A platform-provided hostname automatically assigned to a Site Factory site, usable before or instead of a custom domain; custom domains require DNS and TLS setup.

Site Factory API

A versioned REST interface for automating factory operations such as site creation, cloning, deletion, and user or role management; requests authenticate with API tokens.

Environment separation

Site Factory provides production and non-production environments so code and configuration can be validated before release; production changes should follow the same tested path.

Governance scope rule

Factory-wide privileges should be limited to users who must create, clone, delete, or deploy across sites; site-level administration should be delegated through site groups or per-site roles.

Site creation task

Site creation provisions a new site record, database, and files from a chosen profile or distribution; it runs asynchronously and returns a task that must be monitored.

Site cloning

Cloning copies an existing site's database and files into a new site while leaving the source unchanged; the new site uses the factory's deployed codebase.

Site deletion

Deleting a Site Factory site removes its site record and associated data after confirmation; it is destructive, so verify backups and confirm the correct site first.

Default site domain

The automatically generated hostname for a new site, typically derived from the site name; it lets the site be reached before a custom domain is configured.

Custom domain mapping

Adding a customer-owned hostname to a Site Factory site requires DNS records pointing to the platform and TLS certificate provisioning for that hostname.

Bulk site operations

Site Factory console and API can create, clone, or delete multiple sites in one request; each site becomes an asynchronous task that can succeed or fail independently.

Site name uniqueness

A site's machine name or default domain must be unique within its factory scope; duplicate names cause creation or domain assignment to fail.

Clone source integrity

A clone captures the source site's database and files at the time the task runs; later changes to the source are not included in the already-created clone.

Code deployment pipeline

Site Factory code changes move from version control through a build and deployment process to non-production, then production; the same artifact should be promoted.

Factory-wide code change

Because sites share a codebase, a module or theme update deployed to the factory can affect every site; test across representative sites before production release.

Database update task

After code deployment, Drupal database updates must run for each affected site; Site Factory can run these updates as per-site tasks and report failures.

Non-production first

Deploy code and run updates in the non-production environment before production; this catches site-specific update hook failures without exposing live sites.

Configuration in database

Much Drupal configuration is stored per site in its database, while code and some exported configuration live in the shared codebase; deployments do not automatically sync all site config.

Drush per site

Drush commands in Site Factory target a specific site's database and files through site-specific aliases or the API; they do not run across all sites by default.

Rollback plan

A rollback restores the pre-deployment database backup and redeploys the prior code artifact; both code and database state must be returned to a consistent version.

Update hook failure

If a Drupal update hook fails on one site, that site may remain on the old database schema; isolate the failure, fix the code or data, then rerun that site's update.

Factory user identity

A Site Factory user account is a global identity; access to individual sites or site groups is granted separately from the existence of the account.

Factory administrator

A factory-level role with broad rights to manage sites, users, and deployments across the factory; it should be limited to platform operators who need cross-site control.

Site-level Drupal roles

Drupal roles such as editor or administrator are stored per site database; granting a role on one site does not automatically grant the same role on another site.

Site group access

Membership in a Site Factory site group can grant a user access to all sites in that group; removing membership removes that group-scoped access.

API token permissions

A Site Factory API token acts with the permissions of its associated user or service account; leaking a token exposes exactly those rights until the token is revoked.

Least privilege

Grant only the permissions needed for a user's current task; separate content editing, site administration, and factory administration so no role has unnecessary cross-site power.

User offboarding

When a user leaves, remove their Site Factory account or group memberships and revoke API tokens; otherwise their site and factory access may persist indefinitely.

SSO for Site Factory

Site Factory can integrate with an identity provider so users authenticate through SAML or similar SSO; authorization to sites and roles still comes from Site Factory assignments.