Drupal Professional Standards & Competencies 5 — Questions and Answers
Question 1: A client insists on using a module with a full security advisory and no available patch. What should a professional Drupal developer do?
- Install it anyway since the client accepts the risk verbally
- Refuse all work on the project
- Document the risk formally, obtain written client approval, and implement a compensating control (Correct answer)
- Remove the functionality entirely without consulting the client
Correct answer: Document the risk formally, obtain written client approval, and implement a compensating control
Written acknowledgment plus a compensating control (e.g., WAF rule, access restriction) is the professional approach when a patched alternative doesn't exist yet.
Question 2: What does it mean for a Drupal contrib module to be 'actively maintained'?
- It has at least 100,000 reported installs
- The maintainer regularly reviews issues, applies patches, and releases updates including security fixes (Correct answer)
- It is included in Drupal core distributions
- It passed a one-time Drupal Association review
Correct answer: The maintainer regularly reviews issues, applies patches, and releases updates including security fixes
An actively maintained module has a responsive maintainer who addresses issues and security reports, reducing long-term risk for dependent sites.
Question 3: Which professional standard applies when a Drupal developer reuses substantial portions of another developer's Drupal module in their own project?
- No attribution is needed since all Drupal code is open source
- Credit the original author and ensure the derived work is also GPL-2.0-or-later licensed (Correct answer)
- Only attribution in comments is required, no license consideration
- Obtain a commercial license from the original author
Correct answer: Credit the original author and ensure the derived work is also GPL-2.0-or-later licensed
The GPL-2.0-or-later license requires derivative works to carry the same license and proper attribution to the original authors.
Question 4: When should a Drupal developer use Drush's `drush deploy` command in a CI/CD pipeline?
- Only on local development environments
- As a single command that runs database updates, imports config, and clears caches in the correct order on remote environments (Correct answer)
- To build Composer dependencies during deployment
- To run automated browser tests post-deployment
Correct answer: As a single command that runs database updates, imports config, and clears caches in the correct order on remote environments
`drush deploy` standardizes the deployment sequence (updatedb, config:import, cache:rebuild) ensuring repeatable and correctly ordered operations.
Question 5: A junior developer on your team hardcodes a user role check using a role ID integer instead of the role machine name. Why is this a professional concern?
- Role IDs are always the same across environments, so there is no real issue
- Role IDs can differ between environments, making the code environment-dependent and fragile (Correct answer)
- Hardcoding role IDs improves performance
- Drupal automatically translates role IDs to machine names
Correct answer: Role IDs can differ between environments, making the code environment-dependent and fragile
Role IDs are auto-incremented and may differ between development, staging, and production databases, making machine names the only reliable identifier.
Question 6: Which Git workflow practice is considered a Drupal professional standard when contributing patches to Drupal.org projects?
- Pushing directly to the main branch of the project repository
- Creating a feature branch per issue and opening a merge request linked to the issue on Drupal.org (Correct answer)
- Emailing patches as .diff files to the maintainer
- Forking to a private repository and sharing a ZIP archive
Correct answer: Creating a feature branch per issue and opening a merge request linked to the issue on Drupal.org
Drupal.org's GitLab integration supports merge requests tied to issue queues, which is the expected contribution workflow for modern projects.
Question 7: What is the recommended strategy for handling breaking changes in a custom Drupal module's public API between minor releases?
- Remove deprecated functions immediately to keep the codebase lean
- Mark old functions as deprecated with @deprecated annotations and maintain them for at least one minor release (Correct answer)
- Publish breaking changes without notice since it is a custom module
- Add a BREAKING_CHANGES.txt file but remove the old functions right away
Correct answer: Mark old functions as deprecated with @deprecated annotations and maintain them for at least one minor release
Marking functions deprecated before removal gives downstream consumers time to update, following the same pattern Drupal core uses for its own API transitions.
Drupal Professional Standards & Competencies 5
A client insists on using a module with a full security advisory and no available patch.
What should a professional Drupal developer do?