Acquia Drupal-Site-Builder Acquia Certified Drupal Site Builder Exam for Drupal 10, 11 Exam Practice Test

In Drupal 10 and Drupal 11, a View is stored as configuration , and Drupal provides a built-in Configuration Management system to move configuration between environments. According to the official Drupal User Guide, when you want to move a single configuration item (such as a View), the recommended approach is to use the Single Export and Single Import functionality available in the admin interface.

On the development site, you navigate to Configuration → Development → Configuration synchronization → Export → Single item , select View , and copy the YAML configuration. Then, on the production site, you go to Import → Single item and paste the configuration to import it.

Option A refers to full configuration synchronization, which is typically used for complete site configuration deployment, not for a single View. Option B is incorrect because Backup and Migrate is meant for database backups, not configuration transfer. Option C is incorrect because Drupal provides a UI-based method for this task.

Thus, the correct and documented approach is partial export/import using the single configuration option, making D the correct answer.

In Drupal 10 and Drupal 11, the administrative Comments listing is provided by the core comment View. In core’s default views.view.comment configuration, the comments administration display uses the table style, includes the entity_id field labeled “Posted in” , and that column is present in the table configuration. However, core sets that column’s table option to sortable: false , while other columns such as Subject, Author, and Updated are sortable. That is why moderators cannot sort the approval page by the content item the comment belongs to, even though the field is already there.

Because the existing approval page already uses a View, the simplest solution is to edit that View and enable sorting for the Entity ID / Posted in column in the table settings. Creating a brand-new View would work, but it is not the simplest option because it duplicates an existing administrative display. The other options do not address the actual issue with the current moderation screen. Drupal’s content administration documentation also confirms that comments are managed from the Comments administration page, making improvement of that interface the most appropriate site-building solution.

In Drupal 10 and Drupal 11, the correct way to display resized images (such as thumbnails) is by using Image Styles . Image styles allow Drupal to generate derivative images with specific dimensions (e.g., thumbnail size) and serve those instead of the original full-sized image. This significantly improves performance because smaller image files are loaded, reducing page load time and bandwidth usage.

Drupal’s Image module documentation explains that image styles can apply effects such as scaling, cropping, and resizing, and are typically used in Views or field display settings to ensure appropriately sized images are rendered.

Options C and D (JavaScript and CSS resizing) only change how images appear visually but still load the full-size image , which does not improve performance. Option A refers to performance settings but does not specifically handle image resizing.

Therefore, using an image style is the correct, recommended, and documented approach for optimizing image display and improving site performance.

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.

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.

The main security risk in this scenario is the unrestricted file upload field exposed to anonymous users. Drupal’s file API documentation explains that file uploads must use validation and a defined list of allowed extensions. Core specifically notes that uploading arbitrary files is dangerous and that validation is necessary. The Drupal file API also states that using a managed file field with defined allowed extensions helps sanitize filenames, validate files, and block insecure extensions by default. Without those restrictions, anonymous visitors could upload unsafe files, including malicious or infected files, to the server.

Option A is too broad, because anonymous users can legitimately access public forms on Drupal sites. The issue is not public access by itself, but public access combined with missing validation and upload restrictions . Option C describes a possible performance problem, not the most important security threat identified by Drupal’s documentation. Option D is clearly incorrect because Drupal’s security guidance stresses protecting public forms and validating uploads carefully, especially on forms exposed to anonymous users.

In Drupal 10 and Drupal 11, a module can appear on the Extend page but still have its checkbox unavailable when Drupal determines that its requirements are not met. One of the most common and documented reasons is missing dependencies . Drupal modules declare dependencies in their .info.yml file, and if one or more required modules are not present or enabled, Drupal prevents installation until those dependencies are satisfied. Drupal’s module documentation specifically notes that when a module is listed on admin/modules but its checkbox is disabled, you should verify compatibility and requirements declared in the module metadata.

Option D fits Drupal’s standard dependency behavior. This is also consistent with Drupal community documentation explaining that if you cannot check a module or feature on the module listing page, it is most likely because required dependent modules are missing, and unmet dependencies should be checked first.

The other options are not the correct explanation here. modules/contrib is a valid and standard location for contributed modules, and downloading a module outside the Drupal UI does not itself disable installation. A missing permission would typically affect access to the page or action availability, but the classic reason for a disabled module checkbox on the Extend page is unmet dependencies.

Drupal 10 and Drupal 11 documentation strongly recommend using community-supported channels for troubleshooting contributed modules. The primary and most appropriate place to seek help is the module’s issue queue on drupal.org , where users can search for existing issues, report bugs, and ask questions. This ensures transparency, allows maintainers and contributors to track problems, and benefits the wider community. Therefore, option A is correct.

Additionally, Drupal has active community communication platforms such as Drupal Slack and IRC channels (like #drupal-support), where developers and site builders collaborate and provide real-time assistance. These are officially recognized community support channels, making option B correct.

Option C is incorrect because Drupal project pages do not use general comments for support; instead, all discussions should happen in the issue queue. Option D is discouraged because directly emailing maintainers bypasses the public support process and is not aligned with Drupal community best practices.

Thus, the correct and recommended ways to find help are using the issue queue and community support channels.

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 official security guidance for the super user account ( user 1 ) specifically recommends that administrators do not name the first account “admin” or something obvious . The reason is straightforward: obvious usernames make brute-force and credential-guessing attacks easier, because attackers already know half of the login credentials they need to target. Drupal’s administration and security documentation also recommends limiting direct use of user 1 and protecting it carefully because it is a uniquely powerful account.

That makes option D the correct answer. The other options do not match Drupal’s documented best practices. There is no Drupal security rule about “members of the Drupal community in good standing” being allowed to use user 1. Canceling the user 1 account is not the recommended solution for this situation, and removing the Administrator role from user 1 would not make the account anonymous; in Drupal, user 1 is a special account with superuser behavior that is handled separately from ordinary role assignment. Drupal’s own guidance emphasizes safer naming and tighter handling of the account, not these alternative actions.

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.

Drupal uses text formats and filters to control how HTML input is processed before being displayed. One of the available filters is “Correct faulty and chopped off HTML” , which is specifically designed to fix improperly formatted or broken HTML markup.

According to Drupal documentation, this filter ensures that HTML pasted into editors (like CKEditor) is automatically cleaned and corrected , such as closing unclosed tags, fixing malformed markup, and preventing rendering issues. This is particularly useful when users paste HTML from external sources, which often includes inconsistent or invalid markup.

Option D is correct because it directly addresses the issue at the text format level without restricting allowed tags, maintaining the requirement to allow all HTML elements.

Option C is incorrect because enabling “Limit allowed HTML tags” would restrict HTML usage, which contradicts the requirement to allow all elements. Options A and B are not standard Drupal solutions and do not align with Drupal’s built-in filtering system.

Therefore, enabling the Correct faulty and chopped off HTML filter is the correct and recommended approach in Drupal 10 and Drupal 11.

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.

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.