Describe the capabilities and constraints of the Metadata API for deployment, and how you plan around them.

The Metadata API is the mechanism for retrieving and deploying configuration between orgs in bulk, driven by a package manifest. Change sets and essentially every deployment tool rest on it. It supports the great majority of declarative and programmatic metadata, and it supports destructive changes, which is what lets removals travel with a release.

The constraints that matter architecturally are that coverage is broad but not complete and changes every release; that some org-level feature enablement has to be done in Setup or requested from Salesforce; and that record data is never metadata, so anything held as records needs a separate mechanism.

I plan around this with a deployment runbook that lives in version control next to the code and is reviewed as part of the release. It has an explicit manual pre-deployment and post-deployment section, and I check it against the current Metadata API coverage documentation for each release rather than trusting last quarter's list.

I also distinguish it from the Tooling API in interviews, because they get conflated: you deploy with the Metadata API, and you develop against the Tooling API, which gives fine-grained interactive access to individual components for editors, debugging and test execution.