Draw the distinction: "Options are for site-wide settings — one value for the whole site. Post meta is for per-post data — different values for each post. I use the Settings API to build admin pages that save options with proper nonce verification."
The Options API stores site-wide key-value settings in the wp_options table. Store with update_option(key, value), retrieve with get_option(key, default), delete with delete_option(key). Options are for global settings (site title, permalink structure, plugin settings), not per-post data — that is what post meta is for. Options with autoload set to yes are loaded into memory on every page load for fast access. Strong candidates explain: that plugins should prefix option names to avoid collisions, the Settings API (register_setting, add_settings_section, add_settings_field) for building admin settings pages, that serialised arrays and objects can be stored as a single option, and the performance difference between autoloaded and non-autoloaded options.
Fundamental WordPress data storage question. Candidates who confuse options with post meta or who store per-post data in options have a data architecture gap. Those who understand autoloading and the Settings API build efficient, well-structured plugins.