Design and implement a GenAIOps infrastructure

GenAIOps (generative AI operations) runs generative AI with the discipline of production software: you provision it as code, secure it with identity, version it, and promote it through a pipeline instead of clicking it together by hand. The mental model for this whole domain is three stacked layers of one platform, Microsoft Foundry (formerly Azure AI Foundry, and before that Azure AI Studio): the environment is the secured, provisioned container everything runs in, the models are the foundation models you deploy into it, and the prompts and agents are the application logic that drives those models. One instinct holds across all three layers: prefer the governed, reproducible option over the convenient, ad-hoc one. That instinct is also the exam's favorite trap, because it repeatedly sets a quick portal click or a playground edit beside the declared, access-controlled, pipeline-promoted answer, and the governed answer is almost always the one it wants.

The three subtopics build on one another in the order you would actually stand a system up. First, Foundry Environments and Platform Configuration provisions the platform itself: you create the Foundry resource and a project inside it, give the resource a managed identity so it reaches its dependencies with no stored secret, grant developers a least-privilege role through Azure role-based access control (RBAC) (Foundry User, not Owner), close the network with a managed virtual network (VNet) and a private endpoint, and define it all as code with Bicep (Azure's infrastructure-as-code language, though Terraform is also supported) and the Azure CLI. Second, Deploy and Manage Foundation Models puts models on that platform: you choose the model, decide how to host and bill it (a Microsoft-hosted serverless API versus dedicated managed compute, and within the serverless option, pay-per-token capacity versus reserved capacity), attach a content filter as a live safety guardrail, and set how the deployment takes model version updates. Third, Prompt Versioning and Source Control governs the prompts and agents that drive the models: you keep prompts in Git rather than the playground and manage them as versioned assets, compare variants with Foundry evaluations on a fixed dataset, and promote agents as configuration through a CI/CD (continuous integration and continuous delivery) pipeline. Reach for the first when the question is about where things run and who may touch them, the second when it is about what does the inference and what it costs, and the third when it is about how the application behaves and how a change ships.

Across this whole domain, when two answers are both technically valid, the exam rewards the one a team could reproduce and audit. Prefer a Microsoft Entra ID (Azure's identity service) managed identity over a stored API key, a declared Bicep or pipeline promotion over a manual portal edit, and a least-privilege built-in role over broad Owner or Contributor access. Prefer the consumption default, a serverless pay-per-token deployment, until a measured need such as guaranteed low latency, data residency, or hosting an open-source model forces a dedicated or specialized option. And keep the live guardrail distinct from the offline check: a deployment's content filter blocks harmful content in real time at inference, which is a different job from the evaluations that score a test dataset to gate which prompt version ships.