Plan and Manage an Azure AI Solution
Choosing the resource
A multi-service Azure AI Services resource gives you one endpoint and one key set for many services, which simplifies billing and code - but not every service is supported by the shared key, and some workloads (custom model training, certain vision or speech capabilities) expect a single-service resource. Region availability, pricing tier (F0 free vs S0 standard, one F0 per subscription per service type) and quota limits are exam favourites.
Identity and access
Prefer Microsoft Entra ID over keys. Assign a managed identity to the calling app, then grant a data-plane role such as Cognitive Services User (or the service-specific equivalents like Cognitive Services OpenAI User). Management-plane work needs Cognitive Services Contributor. Keys come in pairs precisely so you can regenerate one while the app uses the other - questions that rotate a single key silently are wrong answers. Where supported, disable local (key) authentication entirely.
Networking and isolation
Public access can be disabled in favour of private endpoints inside a VNet, or restricted with firewall rules and service tags. Plan DNS for private link. Use customer-managed keys in Key Vault when regulation demands control of encryption, and note the extra dependencies this creates.
Operations
Diagnostic settings stream request logs to Log Analytics; metrics feed alerts on latency, errors and throttling. Containers let you run services on-premises or at the edge: they still need to phone home for billing, and fully disconnected containers require a commitment-tier plan.
Traps and rule of thumb
Questions often mix planes (management vs data), assume keys rotate without downtime, or ignore that deleting a resource invalidates both keys and any endpoints baked into code. Rule of thumb: a design that authenticates with managed identity, disables local auth, and uses private endpoints scores every security question.