Emphasise the database caveat: "add_role writes to the database, so I only call it in register_activation_hook or behind a version check. Running it on every request is a wasted database write."
WordPress has five default roles (Administrator, Editor, Author, Contributor, Subscriber), each with a set of capabilities. Capabilities are checked with current_user_can(). Add custom roles with add_role() and modify capabilities with add_cap()/remove_cap(). Critical: these functions write to the database, so wrap them in activation hooks or version checks — do not call them on every page load. Use the Members plugin or custom code for management. Strong candidates discuss: mapping capabilities to custom post types via capability_type and map_meta_cap, the user_has_cap filter for dynamic capability checks, and removing roles/capabilities cleanly on plugin deactivation.
Tests understanding of WordPress access control. Candidates who call add_role on init without guards are wasting database writes. Those who understand capability mapping for custom post types can build proper permission models.