Custom Module and Extension Development
This domain covers module anatomy and the mechanics of extending behavior correctly. A module needs registration.php, etc/module.xml, and a composer.json with correct autoload and dependency declarations. Know the etc/ file roles: di.xml (dependency injection, plugins, preferences, virtual types), events.xml (observers), routes.xml (frontend/admin routes), webapi.xml (REST/GraphQL exposure), db_schema.xml (declarative schema), and acl.xml (admin permissions).
Traps cluster around interception mechanics. Plugins cannot intercept final methods, non-public methods, static methods, or constructors, and before plugins cannot change arguments by reference unless the signature allows it. Sort order among plugins on the same method matters and is set by sortOrder. Observers are fire-and-forget and cannot change return values. Preferences replace a class globally and can silently break other modules' plugins. Also know that di.xml merging happens across modules, so a virtual type is often cleaner than a preference for configuring a shared class differently in one context.
Worked example
Requirement: "Log every call to a repository's save method without altering behavior." Implement an around plugin on the concrete repository class's public save. around receives the subject and a callable $proceed; call $proceed(...$args) and return its result, logging before or after. Do not use an observer, because repository saves are not guaranteed to dispatch a predictable event, and do not use a preference, which would replace the class and risk other modules' plugins.
Questions often test whether you know which file declares what and whether an interception point is legal.