Plan and manage an Azure AI solution
Know the building blocks
Every AI-200 scenario is assembled from the same parts: an Azure AI Services resource (multi-service or single-service), Azure OpenAI model deployments, an Azure AI Search service, a storage account, and - in Foundry-based designs - a hub with one or more projects plus connections to those services. Ask early which boundary owns each setting: identity and networking usually sit at the resource or hub level, while deployments, indexes, and evaluation runs live in the project or service itself.
Security and access
Prefer Microsoft Entra ID with managed identities over account keys. Role names matter: Cognitive Services OpenAI User grants inference on a deployment, Cognitive Services OpenAI Contributor adds fine-tuning and deployment operations, and Azure AI Developer covers Foundry project assets. Questions that ask for the fastest development path may accept keys, but answers that keep shared keys in production are usually wrong.
Capacity and cost
Quota is allocated per subscription and region, per model family, in tokens per minute, and each deployment draws from that pool. Provisioned throughput reserves capacity for steady load; standard pay-as-you-go suits spiky or low volume. Traps: assuming a larger SKU raises quota, or that quota follows the resource into another region.
Operate it
Send diagnostic logs to Log Analytics, watch latency and token metrics, tag resources for chargeback, and confirm dependencies before deleting anything - removing a hub or resource removes its child projects and deployments.
Rule of thumb: one hub (or resource group) per team and security boundary, one project per application and environment. If a setting must differ between dev and prod, it belongs at project level.