Free Acquia Drupal-Site-Builder Practice Exam with Questions & Answers

In Drupal 10 and Drupal 11, block placement is defined per theme . The Block Layout documentation explains that when placing a block, you are assigning it to a region in a specific theme , not globally for all themes. So when you switch the site’s default theme, the new theme may have a different set of regions or different region names, and block placements from the previous theme may no longer map correctly.

Drupal’s theming documentation is even more explicit: if a theme does not define a region that blocks were assigned to, those blocks are treated as assigned to an invalid region and are disabled . The Block module documentation also states that disabled blocks (blocks not assigned to any region in your theme) are never shown . This is exactly why blocks can appear to “disappear” after changing themes.

The other options do not match Drupal’s documented behavior. Blocks do not need to be “registered” with a theme in this sense, contributed themes are not limited to system blocks, and custom blocks generally do not need to be recreated just because the theme changed. The issue is the theme-specific region mapping , which makes D the correct answer.

Because all three content types use a Media reference field that allows the Image media type , the actual uploaded file restrictions are controlled by the source field on the Media type , not by each content type’s reference field. In Drupal, the Image media type contains an image field as its source field, and image/file fields have settings such as allowed file extensions . Drupal’s Image module documentation states that image fields can be configured with settings including allowed extensions .

Therefore, to block GIF uploads everywhere this Image media type is used, you edit the Image media type , go to Manage fields , edit its image source field , and remove gif from the allowed extensions. Since all three content types reference that same media type, the restriction applies consistently across all of them. This is the most efficient and Drupal-native solution.

Option A is incorrect because the media reference field on a content type controls which media types may be referenced, not which file extensions the media type’s source field accepts. Option C concerns form widget display, not file validation. Option D is too general; the actual extension restriction lives on the image field settings within the media type.

Drupal 10 and Drupal 11 let you control block display through visibility conditions on the block configuration form. Drupal’s block management documentation explains that a block’s visibility can depend on page-specific visibility settings and also on user role conditions. For page visibility, Drupal specifically notes that the front page is an exception and must be entered as < front > . To show a block only on the homepage, you add < front > in the Pages visibility settings and choose “Show for the listed pages.”

To limit the block to a specific audience, you use the Roles visibility condition and select the exact role that should see the block. In this case, that is Premium customer , not the broader Authenticated user role, because selecting Authenticated user would show the block to all logged-in users who have that role, not just premium customers. Drupal core’s block form API also confirms that block visibility is built through configurable visibility conditions in the block UI.

So the correct combination is:

A for the role restriction, and B for the front-page-only restriction.

Drupal core search does not index newly created or updated content immediately in the default workflow. According to the official Drupal core Search module overview , content actions such as creating, editing, or deleting content automatically mark the affected content items for indexing or reindexing at the next cron run . Until cron runs, the new or changed content is not updated in the search index, so a newly created article may not appear in search results even though search is otherwise functioning correctly.

This makes option C the correct answer. The other options do not match Drupal core behavior. There is no normal site-building step where you configure core search to “recognize” a specific term, and Drupal does not provide an “Add to search index” checkbox when creating an article in core search. Also, while contributed search solutions exist, the question states that Drupal core search is already working correctly, so the missing result is best explained by indexing timing, not by a flaw requiring another module. Drupal’s search documentation is explicit that cron is responsible for updating the index after content changes.

In Drupal 10 and Drupal 11, content translation is handled through the Content Translation module , which allows you to translate individual content entities (such as nodes). Once multilingual support is enabled and a new language (Spanish) is added, each piece of content provides a Translate tab where translations can be created and managed.

Drupal’s User Guide explains that to translate existing content, you navigate to the content item and use the Translate tab to add a translation in the desired language. This process allows editors to manually enter translated content for each field, ensuring accuracy and proper localization.

Option B is incorrect because Drupal core does not provide automatic Google translation import functionality. Option C refers to interface translation (.po files), which is used for translating the Drupal UI, not site content. Option D is incorrect because Drupal does not provide a bulk “Import Translations” action for node content in this manner.

Therefore, the correct and documented approach is to manually add translations via the Translate tab for each content item, making A 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.

The best answer is B because the problem described is a large volume of 404 Page Not Found requests generated by a crawler, and Drupal core includes Fast 404 handling specifically to reduce the performance cost of such requests. In Drupal 10 and Drupal 11, core contains a Fast404ExceptionHtmlSubscriber and configuration under system.performance:fast_404 . Drupal’s API documentation explains that Fast 404 returns a minimalist 404 response for matching requests instead of going through the full themed page handling, which lowers processing overhead for repeated invalid URL requests.

Option A may help block a bad actor, but banning one IP address is not the Drupal-documented performance feature aimed at reducing the cost of many 404s. Option C would worsen the situation because redirecting missing pages to search adds extra processing rather than reducing it. Option D is incorrect because Drupal does not automatically block suspicious visitors just because they generate many 404 log entries. Also, Drupal 10 release notes explicitly note that Fast 404 is a core capability and that separate legacy settings.php-based handling is no longer the recommended approach.

The most effective and Drupal-recommended way to prevent automated (bot-driven) user registrations is to implement a challenge-response mechanism such as CAPTCHA. In Drupal 10 and Drupal 11, this is achieved using the CAPTCHA module (often paired with reCAPTCHA), which integrates directly into forms like user registration. By enabling a CAPTCHA field on the registration form, bots are prevented from submitting automated requests because they cannot solve the challenge, while legitimate users can proceed normally.

Drupal’s security best practices emphasize mitigating automated abuse at the form level rather than relying solely on post-registration controls. Option A (email verification) still allows bots to create accounts and flood the system, even if they cannot activate them. Option C (hiding login) does not affect registration endpoints and provides no real protection. Option D (restricting registration to administrators only) eliminates self-registration entirely, which may not meet business requirements and is not a balanced solution.

Therefore, enabling CAPTCHA directly addresses the root cause—automated submissions—making it the most appropriate and scalable solution according to Drupal security guidelines.

In Drupal’s official documentation, headless Drupal is described as decoupled Drupal . The documentation explains that decoupled, or headless, Drupal separates the backend content management part of Drupal from the frontend presentation layer . In this architecture, Drupal is used as a content repository and content API, while the frontend can be built with other technologies such as JavaScript frameworks or consumed by other clients. This directly supports option C

Drupal documentation also explains that this architecture allows Drupal content to be exposed to other systems and applications through APIs such as JSON:API or REST. That means Drupal can provide content to websites, mobile apps, kiosks, or other digital channels, which matches option B . The purpose of headless Drupal is therefore not automatic updates or automatic publishing, so options A and D are not correct.

So, according to Drupal 10 and Drupal 11 documentation, the correct understanding is that headless Drupal means decoupled Drupal and involves exposing Drupal-managed content to external systems or applications through APIs .

Drupal 10 and Drupal 11 provide the Layout Builder module in core, which allows site builders and content editors to control how fields are displayed. There are two levels of control: content type–level layouts and per-content (per-node) layout overrides .

Option A only allows rearranging fields globally for all nodes of that content type, which does not meet the requirement of having different layouts per job posting. Option B involves theming and template overrides, which require developer intervention and are not intended for content editors or HR staff.

Option C enables Layout Builder but only at the content type level, meaning all job openings would share the same layout. This still does not satisfy the requirement for different arrangements per node.

Option D is correct because enabling Layout Builder and allowing each content item to have its layout customized activates the “Allow each content item to have its layout customized” setting. Drupal documentation explains that this allows individual nodes to override the default layout, giving flexibility to rearrange fields differently for each job opening while still using a structured, UI-based approach.

Thus, Layout Builder with per-node customization is the correct solution.