Free Practice Questions for Acquia Drupal-Site-Builder Exam

In Drupal 10 and Drupal 11, security updates for contributed modules must be applied promptly to protect the site from known vulnerabilities. Drupal core provides a built-in Update Manager module that notifies administrators when updates, especially security releases, are available. However, Drupal does not automatically install updates , including during cron runs, so option C is incorrect.

The correct process, as documented in Drupal’s official update procedures, involves downloading the latest recommended release of the module (typically via Composer or manual replacement), and then running database updates using the /update.php script or drush updb . This ensures that any schema changes required by the new version are properly applied.

Option B is incorrect because uninstalling a module is unnecessary and can lead to data loss or configuration issues. Option A is clearly wrong, as ignoring security updates exposes the site to risks.

Therefore, the proper and documented approach is to update the module codebase and run update.php to finalize the update process, making option D the correct answer.

Drupal’s configuration management system is specifically designed to move site configuration —such as content types, fields, vocabularies, and Views—between environments by exporting configuration to files and then importing it elsewhere. Drupal documentation explicitly describes configuration as the administrative settings that determine how the site functions, and it lists fields and views as examples of configuration.

That makes option D the correct workflow: build the new fields and View on a development copy of the site, export the configuration to code, deploy that code to staging, import it for QA review, and then repeat the import in production after approval. This preserves live editorial activity such as comments , because comments are site content , not configuration, and configuration deployment avoids overwriting production content with a copied database.

Option A is risky because copying the staging database back to production could overwrite live comments and other newly created production content. Option B is false because staging and production do not automatically share configuration through one database in a normal deployment workflow. Option C is inferior because configuration should be created from a development copy of the actual site, where the existing modules, schema, and site setup already match the target environments.

Drupal 10 and Drupal 11 provide block visibility conditions that allow administrators to control where blocks appear. According to Drupal’s block system documentation, when placing a block through Structure → Block layout , you can configure visibility based on content types, pages, roles, or request paths .

To meet the requirement of showing the "Recent content" block only on Article pages, the correct approach is to place the block in the Sidebar region and configure its visibility condition to Content types → Article . This ensures the block is displayed only when viewing nodes of the Article content type and hidden elsewhere.

Option A is incorrect because using CSS to hide blocks is not a proper Drupal configuration and still renders the block unnecessarily. Options B and C are invalid because Drupal does not provide such settings in content type or site branding configurations.

Thus, using block visibility settings tied to the Article content type is the correct and recommended method in Drupal site building.

In Drupal 10 and Drupal 11, each content item (node) can only have one menu link created through its Menu settings . Drupal documentation explains that the Menu settings section allows you to place a node in a menu, but only as a single menu item . Therefore, you cannot create two menu links for the same node directly from the node edit form, which makes option D incorrect.

The correct approach is to create one menu link via the node’s Menu settings (placing it under “Products”), and then manually add an additional menu link in the Menu administration (Structure → Menus → Main navigation) that points to the same node but is placed under “What’s New.” This matches option A . After the promotion, the temporary menu link can be removed.

Option B is incorrect because duplicating content creates unnecessary redundancy and breaks content management best practices. Option C is incorrect because Drupal core does not provide a built-in “menu link expiration” feature.

Thus, Drupal’s recommended method is to create one menu link via the node and another manually via the menu UI, making A the correct answer.

In Drupal 10 and Drupal 11, content that appears in the sidebar across all pages is typically implemented as a custom block placed in a theme region via the Block Layout system. Drupal documentation explains that reusable content like contact information is best managed through custom blocks , which can be edited centrally and automatically update everywhere they are placed.

Option A is correct because the proper way to update such content is to go to Structure → Block layout → Custom block library , locate the block, and edit it. This ensures the change is reflected globally wherever the block is used.

Option C is also correct because Drupal provides contextual links (the pencil icon) that allow administrators to directly edit blocks from the front end. This is a standard and documented shortcut for editing block content.

Option B is incorrect because Layout Builder is not mentioned and is not required here. Option D is incorrect because editing individual pages would not update a shared sidebar block and would be inefficient and incorrect.

Thus, the correct Drupal site-building approaches are editing the custom block via the block library or using contextual links, making A and C correct.