Welcome to Part 2 of our comprehensive study series for the AI-103 Certification. In Part 1, we evaluated model selection. Now, we tackle enterprise governance in Microsoft Foundry (formerly Azure AI Foundry). This free practice module covers Hub vs. Project resource inheritance, Microsoft Entra ID role-based access control (RBAC), Managed Virtual Networks, Private Endpoints, Key Vault secrets, and TPM quota distribution.
 |
| Microsoft Foundry Security & Governance: AI-103 Certification Practice Questions |
In this free AI-103 practice exam module, you will solve 20 realistic architectural scenarios focusing on control-plane vs. data-plane permissions, network isolation tiers, and multi-project governance. Each question includes verified explanations for all options.
Microsoft Foundry Security & Setup Practice Questions (Part 2)
Q1: Keyless SDK Authentication (DefaultAzureCredential & Agent Retrieval)
You are writing a Python script using the Azure AI Projects SDK to allow a development team to access an existing AI agent named "Agent1". The solution must meet organizational security and compliance requirements by avoiding the use of hardcoded keys.
You have the following incomplete code:
from azure.identity import DefaultAzureCredential
from azure.ai.projects import AIProjectClient
from azure.core.credentials import AzureKeyCredential
myEndpoint = "https://contoso.services.ai.azure.com/api/projects/project1"
project_client = AIProjectClient(
endpoint=myEndpoint,
credential=[Blank 1]
)
myAgent = "Agent1"
agent = project_client.agents.[Blank 2](agent_name=myAgent)
print(f"Retrieved agent: {agent.name}")Which values should you use to complete the code?
• B is correct: DefaultAzureCredential() supports Microsoft Entra ID authentication, fulfilling enterprise security and compliance requirements by avoiding hardcoded secrets. The get method is the correct function within the agents client to retrieve an existing agent by its identifier.
• A is incorrect: While get is the correct method to retrieve the agent, AzureKeyCredential() relies on static API keys. This does not meet strict security and compliance requirements, which typically mandate role-based access control (RBAC) and identity-based authentication.
• C is incorrect: DefaultAzureCredential() is correct for authentication, but get_version is not the standard SDK method used to retrieve the primary agent object context in this scenario.
• D is incorrect: AzureKeyCredential() violates the security requirement to avoid static keys. Additionally, create_version is used for creating new iterations of a resource, not retrieving an existing one for access.
Q2: Multi-Project Resource Isolation (Project Scoping vs Resource Sharing)
A Microsoft Foundry resource hosts several projects belonging to different application teams. You need to ensure that an agent in one project can only consume the models, search indexes, and data connections that are scoped to its own project, and can never reach a connection that belongs to another project under the same Foundry resource.
Which approach achieves this isolation?
• C is correct: a connection created at the Foundry resource level is available to every project under that resource, subject to project permissions — so the connection's scope (resource-wide vs. project-only) is what creates the isolation boundary in the first place. Once it's scoped to one project, a project-scoped role (Foundry User or Foundry Project Manager) controls who on that project can use it, without exposing it to any other project.
• A is incorrect: CORS governs which browser origins can call an API; it has no bearing on cross-project authorization.
• B is incorrect: VNet private endpoints secure network traffic to the Foundry resource as a whole; they don't create a logical boundary between projects sharing that resource.
• D is incorrect: despite its name, Azure AI Developer is scoped to Azure Machine Learning workspaces and Foundry (classic) hubs, not to Foundry projects — Microsoft's own guidance says to use Foundry User or Foundry Project Manager instead. Even setting that aside, assigning any role at the resource scope, rather than the project scope, grants it across every project, defeating the isolation goal.
Q3: Rate Limiting & Capacity Allocation (Tokens per Minute Quota)
During the configuration of a new generative AI model deployment in Azure OpenAI Studio, you must establish rate limits. The application must be restricted on the maximum volume of text tokens it can process within a 60-second window to prevent capacity exhaustion and runaway costs.
Which deployment setting must you adjust to enforce this limit?
• Why C is correct: The Tokens per Minute (TPM) quota is the primary rate-limiting and capacity allocation metric in Azure OpenAI deployments. It enforces a strict upper limit on the aggregate sum of input (prompt) and output (completion) tokens processed per minute. When clients exceed this threshold, the API throttles incoming requests and returns an HTTP 429 Too Many Requests error.
• Why A is incorrect: Content filtering strictness configures safety guardrails against harmful content categories (hate speech, sexual content, violence, and self-harm) and jailbreak attempts; it has no effect on request frequency, token volumes, or rate limiting.
• Why B is incorrect: Storage redundancy (such as LRS or GRS) applies to Azure Storage accounts for data durability and high availability. It is completely unrelated to model inference throughput or API rate limits.
• Why D is incorrect: The system message sets the model’s guiding persona and constraints. While each model architecture supports a maximum context window length per call (such as 128k tokens), this defines per-request memory capacity, not a 60-second rate-limiting quota across multiple requests.
Q4: Multi-Tenant Capacity & Financial Governance (Select 2)
An enterprise IT department manages a shared Azure environment supporting multiple internal business units. The platform architecture team must ensure that:
• No single model deployment monopolizes the region's provisioned token processing capacity.
• Monthly spending across deployments does not exceed allocated departmental budgets.
Which TWO controls should the team configure to achieve these objectives? (Each correct selection forms part of the complete solution.)
• Why A is correct: Setting a specific Tokens per Minute (TPM) quota on individual Azure OpenAI deployments prevents any single application or team from exhausting the subscription's regional token pool, ensuring fair capacity distribution across projects.
• Why B is correct: Azure Cost Management budgets allow administrators to define monetary caps at the subscription, resource group, or resource level. They trigger proactive alerts and automated actions before resource consumption leads to budget overruns.
Why the other options are incorrect:
• Why C is incorrect: Content Safety blocklists filter out forbidden words, hate speech, or proprietary secrets from prompts and completions. They are safety guardrails, not capacity or financial governance controls.
• Why D is incorrect: Semantic ranker re-ranking depth determines how many document chunks are evaluated by deep neural models in Azure AI Search. It is a search relevance tuning property, not a model capacity or financial spend control.
• Why E is incorrect: Speech audio compression affects network bandwidth and audio streaming quality; it does not govern LLM token quotas or cloud infrastructure spend caps.
Q5: Centralized Microservice Governance (Azure AI Foundry Project)
Developers are architecting a modular generative AI application composed of multiple backend microservices. The application needs to interact with language models, autonomous agents, and data source connectors managed from a single control plane, avoiding the need to hard-code API keys, deployment URLs, and credentials across multiple codebases.
Which architectural construct should the microservices connect to?
• Why B is correct: An Azure AI Foundry project serves as the centralized workspace and logical management boundary for generative AI assets. By instantiating AIProjectClient from the Azure AI Foundry SDK, client applications authenticate once (via Microsoft Entra ID) to the project. The project then abstracts and centralizes access to model deployments, agent configurations, evaluations, and enterprise connections without requiring hard-coded credentials in client code.
• Why A is incorrect: Storing connection metadata in Azure Blob Storage with hard-coded SAS tokens is an anti-pattern. It creates serious security vulnerabilities, lacks native lifecycle management for AI assets, and does not provide an SDK client for invoking models or managing agents.
• Why C is incorrect: Distributing configurations across isolated local files (such as appsettings.json or .env files) duplicates configuration across codebases. Any model update or credential rotation requires updating and redeploying every microservice independently.
• Why D is incorrect: Connecting directly to individual public endpoints bypasses centralized Foundry governance, forcing each microservice to manage separate API keys, versions, and endpoint URLs individually.
Q6: Single-Tenant Dedicated Isolation (Managed Compute & Private VNet)
A defense contractor must deploy an open-source large language model from the Microsoft Foundry model catalog. To satisfy rigorous compliance requirements, the model must run on dedicated compute capacity that is never shared with other tenants, with the deployment's traffic confined entirely to the organization's private Azure Virtual Network (VNet) and zero inbound public internet traversal.
Which deployment option in Microsoft Foundry, correctly configured, satisfies these security and network isolation requirements?
• A is correct: Managed compute provisions capacity dedicated exclusively to your workload instead of Microsoft's shared multi-tenant infrastructure — the "not shared with other tenants" half of the requirement. Reaching "zero inbound public internet traversal" additionally requires securing the Foundry resource itself: a private endpoint so inbound client traffic never touches the public internet, and a managed virtual network configured for approved-outbound-only so the deployment's own outbound calls stay private too. Dedicated compute makes this isolation possible; the private endpoint and managed virtual network are what actually enforce it.
• B is incorrect: Serverless API deployments (Pay-as-you-go / Models-as-a-Service) host models on shared, multi-tenant infrastructure managed by Microsoft. While secure and billed per token, they don't provide dedicated, single-tenant compute or run inside your private VNet.
• C is incorrect: an anonymous endpoint allows unauthenticated, public traffic to invoke inference calls, which directly violates the zero-public-inbound requirement.
• D is incorrect: a shared multi-tenant serverless endpoint distributes requests across pooled infrastructure; it provides neither dedicated instances nor private network isolation.
Q7: Passwordless Authentication (Microsoft Entra Managed Identities & RBAC)
An enterprise security policy requires that microservices connecting to Azure AI services must never store static API access keys in application configuration files, deployment settings, or source code.
Which authentication approach best satisfies this security mandate?
• Why B is correct: Azure Managed Identities eliminate the need for developers to manage, store, or rotate static secrets. The application authenticates securely to Azure AI services using Microsoft Entra ID tokens, and fine-grained authorization is governed by Azure Role-Based Access Control (RBAC) roles (such as Cognitive Services OpenAI User).
• Why A is incorrect: Storing API keys in environment variables still exposes static, long-lived credentials in plaintext on the host operating system, making them vulnerable to process inspection, container dump logs, and credential leakage.
• Why C is incorrect: Sharing a single static key across multiple environments violates the principle of least privilege, eliminates auditability per environment, and creates a critical vulnerability if the key is compromised.
• Why D is incorrect: Committing credentials into source control—even in encrypted form—is a major security anti-pattern and violates cloud security governance policies.
Q8: Automated Spike Prevention (Azure Monitor Metric Alerts & Action Groups)
An operations administrator needs to prevent unexpected billing spikes caused by runaway agentic loops. The team must receive automated email and webhook notifications whenever an Azure OpenAI deployment's daily token consumption crosses a defined threshold.
Which Azure capability should you configure to satisfy this requirement?
• C is correct: Azure OpenAI automatically publishes token consumption metrics — including Processed Prompt Tokens, Generated Completion Tokens, and Processed Inference Tokens (prompt and completion combined) — to Azure Monitor. By configuring an Azure Monitor metric alert rule against these metrics and linking it to an Action Group, administrators can automatically trigger email alerts, SMS notifications, or webhook automation when consumption crosses predefined daily limits.
• A is incorrect: Azure Site Recovery orchestrates business continuity and disaster recovery by replicating physical and virtual machines between Azure regions or on-premises datacenters; it doesn't track API metrics or token quotas.
• B is incorrect: Azure Bastion provides browser-based, secure RDP and SSH administrative access to virtual machines without public IPs; it's an infrastructure access tool, not an alerting service.
• D is incorrect: Azure Migrate discovers, assesses, and migrates on-premises servers, databases, and web apps to Azure; it plays no role in monitoring cloud AI usage.
Q9: Audit Logging & KQL Compliance (Azure Monitor Diagnostic Settings)
A financial services company runs an Azure OpenAI resource in production. An internal auditor must be able to show, for any day in the past 90 days, which deployments received API calls, at what time, from which caller identity, and whether each call succeeded or was throttled. The team requires resource-level platform logging with no changes to application code, and the records must be queryable with KQL.
What should the team configure on the Azure OpenAI resource?
• Why this answer is correct:
- Zero Code Changes (Resource-Level): Azure Monitor Diagnostic Settings are configured directly on the Azure OpenAI / Cognitive Services resource control plane. They capture incoming API traffic natively without requiring any client-side code modifications or SDK instrumentation.
- Required Log Categories: RequestResponse records granular API invocation telemetry, including exact timestamps, targeted model deployment names, and HTTP response status codes (e.g., 200 OK for successes vs. 429 Too Many Requests for throttled calls). Audit captures authentication events, caller identities, and source IP addresses.
- KQL & Retention Compliance: Routing these diagnostic categories to a Log Analytics workspace allows the auditor to run Kusto Query Language (KQL) queries across the ingested tables (such as AzureDiagnostics), and configuring retention to ≥ 90 days satisfies the historical audit requirement.
• Why the other options are incorrect:
- Storage lifecycle management is incorrect: Storage policies simply transition existing blob files between access tiers (Hot, Cool, Cold, Archive). A storage policy does not capture API traffic from Azure OpenAI, nor does Blob Storage provide a native KQL query interface.
- Metrics blade is incorrect: Azure Monitor Metrics are aggregated numerical time-series data. Metrics do not log individual call transactions, request-level timestamps, or specific caller identities, making it impossible to trace individual audit events.
- Adding OpenTelemetry is incorrect: This option explicitly violates the requirement: "with no changes to application code." Modifying client code with OpenTelemetry SDKs is application-level instrumentation, not platform-level logging.
Q10: Data-at-Rest Encryption Control (Customer-Managed Keys in Key Vault)
A healthcare organization deploying Azure OpenAI must retain full administrative control over the encryption keys protecting data at rest, including the ability to instantly revoke the service's access to that data by disabling the key — independent of Microsoft-managed key rotation.
Which encryption configuration should you implement?
• Why B is correct: Customer-managed keys let you store and control your own encryption key in Azure Key Vault, and reference it from the Azure OpenAI resource. Because you own the key, you can revoke, rotate, or disable it at any time, which immediately cuts off the service's ability to decrypt the data — a level of control Microsoft-managed keys don't offer.
• Why A is incorrect: Microsoft-managed keys still encrypt data at rest, but Microsoft controls key lifecycle and rotation; the customer has no way to independently revoke access via the key.
• Why C is incorrect: TLS 1.2 secures data in transit between client and endpoint; it has no bearing on how data is encrypted at rest.
• Why D is incorrect: Azure Disk Encryption applies to IaaS virtual machine disks. Azure OpenAI is a managed PaaS service and doesn't expose the underlying VM disks for the customer to encrypt directly.
Q11: Multi-Tenant Enterprise Gateway (Azure API Management Pattern)
A large enterprise has 12 internal application teams, each needing access to the same set of Azure OpenAI models. The platform team wants a single entry point that can apply consistent per-team rate limiting, track token usage per team for internal chargeback, and rotate the underlying Azure OpenAI keys without requiring any application team to change their code.
Which architectural component should sit between the application teams and the Azure OpenAI deployments?
• Why this is correct: Placing Azure API Management in front of Azure OpenAI lets the platform team define per-team subscription keys, apply rate-limiting and quota policies per subscription, and log usage centrally for chargeback — all while application teams call a stable APIM endpoint. Backend key rotation happens behind APIM, transparent to callers.
• Why "Direct per-team Azure OpenAI resource keys" is incorrect: Distributing raw resource keys to 12 teams means every key rotation requires updating every team's application, and there's no centralized layer to enforce consistent per-team rate limits or chargeback tracking.
• Why "Azure Load Balancer in round-robin mode" is incorrect: A basic load balancer distributes network traffic across backend instances; it has no concept of per-team policy, token-usage metering, or subscription-based rate limiting.
Q12: Automated Deployment Guardrails (Azure Policy Deny Effect)
A company's cloud governance team must ensure that, organization-wide, developers can only deploy Azure OpenAI models from an approved list, and only into a specific set of approved Azure regions — enforced automatically, with any non-compliant deployment attempt blocked before it succeeds.
Which Azure capability should the governance team use?
• Why D is correct: Azure Policy lets you define rules that evaluate resource properties (such as model name or deployment region) against allowed values, and enforce them with a "deny" effect that blocks non-compliant deployments at creation time — exactly the preventive, automated enforcement described.
• Why A is incorrect: Cost Management budgets track and alert on spending; they don't inspect or block which models or regions a deployment uses.
• Why B is incorrect: Defender for Cloud's secure score reflects your overall security posture and provides recommendations; it isn't a preventive enforcement mechanism for deployment-time governance rules.
• Why C is incorrect: Azure Advisor provides best-practice recommendations after the fact; it doesn't proactively block a non-compliant deployment from being created.
Q13: Regional High Availability & PTU Portability (Yes/No)
For each of the following statements about business continuity for a production Azure OpenAI workload, select Yes if the statement is true. Otherwise, select No.
1. Deploying the same model to Azure OpenAI resources in two different regions, and routing traffic between them with Azure API Management or Azure Front Door, is a valid pattern to achieve regional failover.
2. A single Azure OpenAI deployment in one region automatically fails over to another Azure region if that region experiences an outage, with no additional configuration required.
3. Provisioned (PTU) capacity purchased in one region can be seamlessly used to serve traffic from a different, unconfigured region during a regional outage.
• Statement 1 is Yes: Because a single Azure OpenAI resource is scoped to one region, achieving cross-region resilience requires deploying the model in multiple regions and using a routing layer (such as APIM policies or Azure Front Door) to detect failures and redirect traffic to a healthy region.
• Statement 2 is No: Azure OpenAI does not provide automatic, zero-configuration cross-region failover. If the region hosting a deployment goes down, that deployment is unavailable until the architecture routes traffic elsewhere — which must be explicitly designed and configured.
• Statement 3 is No: Provisioned Throughput Units are reserved and tied to the specific region and deployment they were purchased for; they do not automatically extend or transfer their reserved capacity to a different region during an outage.
Q14: Accidental Resource Deletion Prevention (Soft Delete & Purge Protection)
An administrator accidentally deletes a production Azure OpenAI resource that had customer-managed key encryption and several active deployments. The organization's policy requires that such a resource be recoverable within a defined retention window rather than being immediately and permanently erased.
Which Azure Cognitive Services / Azure OpenAI feature ensures this recovery window exists?
• Why C is correct: Azure Cognitive Services resources, including Azure OpenAI, support soft delete: a deleted resource is retained in a recoverable state for a default retention period rather than being purged immediately. Enabling purge protection additionally prevents anyone — including someone with sufficient permissions — from permanently purging the resource before that retention period ends, guarding against accidental or malicious permanent deletion.
• Why A is incorrect: Azure Backup vaults protect workloads like VMs, databases, and file shares; they don't apply to the Cognitive Services/Azure OpenAI resource type's own deletion lifecycle.
• Why B is incorrect: Azure Site Recovery replicates VMs and physical servers for disaster recovery; it has no role in recovering a deleted Cognitive Services resource.
• Why D is incorrect: Blob Storage versioning protects individual blob objects in a storage account from overwrite or deletion; it doesn't apply to the Azure OpenAI resource itself.
Q15: Complete Public Isolation (Private Endpoint & Disabled Public Access - Select 2)
A company requires that its Azure OpenAI resource be completely unreachable from the public internet, while remaining accessible from applications running inside its own Azure Virtual Network (VNet).
Which TWO configuration steps are required together to achieve this? (Each correct selection forms part of the complete solution.)
• Why B is correct: Disabling public network access closes off the resource's public endpoint entirely — without this, the resource remains reachable from the internet regardless of any private connectivity you add.
• Why D is correct: A private endpoint gives the resource a private IP address inside the VNet, and the matching private DNS zone ensures the resource's standard hostname resolves to that private IP for VNet clients — this is what actually makes the resource reachable privately once public access is disabled.
Why the other options are incorrect:
• Why A is incorrect: Firewall IP allow-listing while public network access stays enabled still exposes a public endpoint; it restricts by source IP but doesn't achieve "completely unreachable from the public internet," and it's a different (weaker) mechanism than the resource being fully private.
• Why C is incorrect: TPM quota controls throughput/rate limiting, not network reachability.
• Why E is incorrect: Blocking port 443 outbound on the client subnet would prevent the client application itself from reaching anything over HTTPS, including the private endpoint — it doesn't selectively secure the Azure OpenAI resource.
Q16: Control-Plane vs Data-Plane RBAC (Cognitive Services Contributor Trap)
A platform engineer assigns a data scientist the Cognitive Services Contributor role, scoped to the Azure OpenAI resource, expecting this to let the data scientist call the chat completions API using their own Microsoft Entra ID identity. When the data scientist tries to call the API with Entra ID authentication, the call fails with an authorization error.
What is the most likely cause of the failure?
• Why A is correct: Azure RBAC on Cognitive Services/Azure OpenAI separates control-plane permissions (creating, configuring, and managing the resource, including reading API keys) from data-plane permissions (actually invoking the model). Cognitive Services Contributor grants the former but not the data action required to call the inference API. The data scientist needs a role such as Cognitive Services OpenAI User (or OpenAI Contributor) to make authenticated inference calls with their own identity.
• Why B is incorrect: Microsoft 365 licensing is unrelated to Azure RBAC authorization for Cognitive Services resources.
• Why C is incorrect: A quota-exceeded failure returns a distinct throttling error (HTTP 429), not a general authorization failure, and nothing in the scenario indicates quota exhaustion.
• Why D is incorrect: Entra ID (Microsoft Entra) authentication works with roles that include the relevant data actions; the issue here isn't the authentication method, it's that the assigned role lacks the data-plane permission regardless of how the request is authenticated.
Q17: Secure Database Grounding (Private Endpoint & Passwordless Entra ID - Select 2)
An Azure AI Foundry agent needs to query a customer's existing Azure SQL Database through a Foundry connection. Security requirements state that the database must not be reachable from the public internet, and the connection must not store a SQL username and password anywhere in the connection configuration.
Which TWO configurations satisfy these requirements? (Each correct selection forms part of the complete solution.)
• Why B is correct: A private endpoint gives the Azure SQL Database a private IP within the VNet, removing its public endpoint exposure and satisfying the "not reachable from the public internet" requirement, as long as the Foundry project's connection also routes through that same VNet.
• Why E is correct: Authenticating with Microsoft Entra ID / a managed identity means no SQL username or password is stored in the connection at all — access is granted and revoked through Entra ID role assignments on the database instead of a stored credential.
Why the other options are incorrect:
• Why A is incorrect: This directly violates the requirement — storing a username and password in the connection is exactly the credential-storage pattern to avoid.
• Why C is incorrect: This firewall setting still relies on the database having a public endpoint reachable by Azure's backend network; it does not make the database privately reachable only through the customer's own VNet, and it's broader than intended (it allows any Azure-hosted resource, not just this specific VNet).
• Why D is incorrect: DTU tier affects database performance/throughput, not network exposure or credential handling.
Q18: Key Vault Access with Azure RBAC (Key Vault Secrets User)
A Foundry project connection needs to read a secret from an Azure Key Vault that uses the Azure RBAC permission model (not the legacy vault access policy model). The connection authenticates using the Foundry project's system-assigned managed identity.
Which action must you take so the managed identity can successfully retrieve the secret?
• Why B is correct: When a Key Vault is configured to use the Azure RBAC permission model, access is controlled exclusively through Azure role assignments, not the legacy access-policy list. The Key Vault Secrets User role grants read access to secret contents, which is what the managed identity needs.
• Why A is incorrect: Access policies are the legacy permission model. When a vault is configured for Azure RBAC, access policies are ignored entirely — configuring one has no effect.
• Why C is incorrect: Azure Key Vault doesn't expose a general "access key" the way Storage accounts do, and hardcoding any such secret into the connection configuration would also violate the goal of using managed identity authentication.
• Why D is incorrect: Access is never automatic; every principal, including a managed identity, must be explicitly granted a role (RBAC model) or a policy entry (access-policy model) before it can read a secret.
Q19: PTU Regional Scoping & Resilience
A company purchased Provisioned Throughput Units (PTUs) for a GPT-4o deployment in the East US region to guarantee dedicated capacity. During a regional capacity constraint, the platform team wants to immediately redirect that same reserved throughput to serve requests from a deployment in the West Europe region instead, without purchasing anything new.
Is this possible, and why?
• Why B is correct: Provisioned Throughput Units reserve dedicated compute capacity tied to the specific model and region/deployment they were purchased for. They are not a portable, subscription-wide pool that can be redirected to a different region on demand — achieving multi-region resilience with PTUs requires provisioning and paying for separate PTU capacity in each region.
• Why A is incorrect: This describes a flexible, cross-region pooled resource, which is not how PTU reservations work; each reservation is scoped to where it was provisioned.
• Why C is incorrect: Global Standard is a separate, distinct deployment type from Provisioned; PTU capacity isn't something you fold into a Global Standard deployment to make it cross-region.
• Why D is incorrect: PTU-based deployments are specifically designed for real-time, low-latency inference with predictable throughput — the opposite of the asynchronous Batch API use case.
Q20: Azure Security & Governance Capabilities (Matching)
Match each Azure capability to its primary security or governance role when setting up and securing an Azure AI Foundry solution. Each capability is used exactly once.
1. Stores and controls access to secrets, connection strings, and encryption keys used by a solution's connections.
2. Enforces organization-wide rules on what can be deployed (such as approved models or approved regions), blocking non-compliant resources at creation time.
3. Detects when a resource's usage or configuration crosses a defined threshold and automatically triggers a notification or automated remediation action.
4. Gives a resource a private IP address inside a virtual network, removing the need for it to be reachable over the public internet.
5. Determines which specific actions (control-plane or data-plane) a given identity is allowed to perform on a resource.
• 1 → Azure Key Vault: Key Vault is the centralized store for secrets, connection strings, and encryption keys, so that credentials aren't hardcoded into application code or connection configurations.
• 2 → Azure Policy: Policy evaluates resource properties against organization-defined rules and can deny non-compliant deployments before they're created, enforcing standards like an approved-models or approved-regions list.
• 3 → Azure Monitor: Metric alerts watch telemetry such as token consumption or request failures, and Action Groups turn a threshold breach into an automated notification (email, webhook) or remediation action.
• 4 → Private Endpoint: A private endpoint projects a resource into a VNet with a private IP, letting you disable public network access while keeping the resource reachable to clients inside that network.
• 5 → Azure RBAC: RBAC role assignments define exactly which control-plane actions (manage the resource) and data-plane actions (call the model, read secrets) a given user or managed identity can perform — the distinction that trips people up between roles like Cognitive Services Contributor and Cognitive Services OpenAI User.
Microsoft Foundry Security Cheat Sheet: Architecture & Network Tiers
Passing the AI-103 Azure AI Apps and Agents Developer Associate certification requires knowing how security boundaries behave in production. Use this reference guide to navigate Hub-to-Project inheritance and network isolation options:
| Architectural Level | Managed Resources & Scope | Key AI-103 Decision Factor |
|---|---|---|
| Foundry Hub | Parent boundary. Hosts shared Azure Storage accounts, Key Vaults, Container Registries, and regional TPM quota pools. | Provision once to share foundational infrastructure and enterprise connections across multiple teams. |
| Foundry Project | Child workspace. Isolates custom models, agent setups, and evaluations. Inherits Hub resources automatically. | Create separate projects for individual teams. Scope data connections here to prevent cross-team access. |
| IP Firewall Allow-List | Restricts access by public client IP. The service endpoint remains publicly resolvable on the internet. | Low-effort baseline. Does not meet zero-trust or compliance mandates requiring private connectivity. |
| Managed VNet (Approved Outbound) | Secures outbound traffic from model runtimes and agents using predefined Azure service tags or FQDN rules. | Prevents data exfiltration by blocking unauthorized outbound internet calls from running workloads. |
| Private Endpoint + Disable Public Access | Assigns a private IP from your VNet. Disabling public network access removes the public endpoint entirely. | The gold standard for enterprise security. Traffic never leaves the private Microsoft backbone network. |
| Managed Identity + Entra ID RBAC | Passwordless authentication using Azure tokens. Replaces static API keys in code and connection files. | Enforces least privilege. Separates control-plane management from data-plane model inference. |
Key Takeaways for AI-103 Domain 1 (Foundry Security & Setup)
• The Core RBAC Trap:
Cognitive Services Contributoronly manages the resource control plane (creating deployments, rotating keys). It cannot invoke the chat completions API. To make inference calls with an Entra ID identity, users need a data-plane role likeCognitive Services OpenAI User.• Project-Level Connection Scoping: Connections created at the Hub level are visible across projects. To isolate sensitive data (like a proprietary Azure SQL database), create the connection directly inside the target Project and assign users the
Foundry Userrole.• Complete Network Lockdown: Adding an IP allow-list still leaves a resource accessible over the public internet. True network isolation requires two paired actions: disabling public network access and provisioning a Private Endpoint with a linked Private DNS Zone.
• Zero-Code Audit Trails: Use Azure Monitor Diagnostic Settings to send
RequestResponse(captures HTTP status codes like 429 throttling) andAuditlogs (captures caller identities) directly to a Log Analytics workspace for KQL analysis without modifying application code.• Key Revocation & Disaster Recovery: Customer-Managed Keys (CMK) in Azure Key Vault allow instant data access revocation. To protect against accidental deletions, ensure Soft Delete with Purge Protection is enabled on your Cognitive Services resources.
Frequently Asked Questions (Foundry Setup & Security FAQ)
Review clear answers to the most common security and architecture questions tested on the AI-103 exam:
What is the difference between a Foundry Hub and a Foundry Project?
A Foundry Hub is the top-level parent resource that manages shared infrastructure, including storage accounts, Key Vaults, container registries, and enterprise connections. A Foundry Project is a child workspace under the Hub where development teams build agents, deploy models, and run evaluations within an isolated project boundary.
Which Azure role allows a developer to call OpenAI models without reading API keys?
The Cognitive Services OpenAI User role provides the necessary data-plane permissions to run model inference using Microsoft Entra ID authentication. Unlike Cognitive Services Contributor, it prevents developers from viewing, creating, or rotating static resource API keys, enforcing the principle of least privilege.
Why is a Private Endpoint needed if an IP firewall allow-list is already enabled?
An IP firewall allow-list only filters incoming traffic by source IP address, leaving the resource endpoint publicly accessible on the internet. A Private Endpoint assigns a private IP inside your virtual network, allowing you to completely disable public network access and eliminate internet-facing attack surfaces.
When is Customer-Managed Key (CMK) encryption required in Microsoft Foundry?
Customer-Managed Key (CMK) encryption is required when strict regulatory standards mandate that your organization retains full administrative ownership of encryption keys. CMK enables instant access revocation by disabling the key in Azure Key Vault, whereas Microsoft-managed keys rotate automatically without customer-triggered revocation controls.
Can Azure OpenAI Tokens per Minute (TPM) quota be distributed across multiple projects?
Yes. Administrators manage a central regional quota pool at the subscription and Hub level, then allocate specific Tokens per Minute (TPM) limits to individual model deployments inside each project. This ensures predictable throughput and prevents any single application from monopolizing shared capacity.
Next Step in Your AI-103 Certification Journey
Congratulations on completing Part 2! You now understand how to structure Microsoft Foundry hubs, enforce least-privilege RBAC roles, protect networks with Private Endpoints, and govern multi-team token budgets across enterprise projects.
