1.2.1. Resource, Project, Deployment, Agent
💡 First Principle: Each layer owns a different concern — resource owns identity/billing/region, project owns workspace/connections/access, deployment owns a model-version-and-quota, agent owns instructions-tools-knowledge-state. When a scenario asks where to configure something, match the concern to the layer.
This diagram is worth internalizing because it answers a whole class of questions at once. Where do I set RBAC for who can use this workspace? Project. Where is region and the customer-managed key chosen? Resource. Where do I pick model version and set tokens-per-minute quota? Deployment. Where do I attach a Bing grounding tool and a system instruction? Agent. Region availability in particular is a frequent trap: a given model may exist in the catalog but not be deployable in your resource's region, so region (a resource-level concern) constrains deployment (a project-level action).
⚠️ Exam Trap: Tokens-per-minute (TPM) quota is granted at the subscription level (per region and model) and then allocated per deployment — not per resource or per project. A scenario where one application is starving another of capacity is usually solved by rebalancing deployment-level TPM or using separate deployments — not by changing the resource.
Reflection Question: Two teams share one Foundry resource but need different model-access permissions and different connected data sources. At which layer do you separate them, and what stays shared?
