Split Shared Foundry Azure OpenAI Costs by Project in Cost Management

AI-500 By islever Editorial Last updated

Design and implement observability and monitoring for multi-agent solutions

Short answer

B Use Cost Analysis scoped to the Foundry resource, group by Resource, and save a view for each project so shared Azure OpenAI spend is split without manual tagging.

Question

You have a Microsoft Foundry resource that hosts Azure OpenAI model deployments for three projects. Each project is for a different business unit. The projects share the same Foundry resource.
You need to implement a Microsoft Cost Management view that separates the shared model spend by the project. The solution must meet the following requirements:
Use cost data that can be reconciled by using Azure Cost Management.
Minimize manual tagging.
What should you use?
  1. cost analysis scoped to the resource group with grouping by Meter and exports for each project
  2. cost analysis scoped to the Foundry resource with grouping by Resource and saved views for each project Correct Answer
  3. cost analysis scoped to the Foundry resource with a tag filter on project
  4. cost analysis scoped to the subscription with a Service tier: Azure OpenAI filter and budgets for each business unit

Key Takeaways

It tests whether you can choose a native Cost Management breakdown for shared Foundry model deployments instead of relying on manual tags or budgets.

This AI-500 scenario asks how to split shared Azure OpenAI model spend across three Foundry projects using Microsoft Cost Management while minimizing tags. The correct approach is Cost Analysis scoped to the Foundry resource, grouped by Resource, with saved views per project (B).

Common mistake: The most plausible wrong answer is C: a project tag filter seems like natural chargeback, but it requires manual tagging and cannot reliably split a shared Foundry resource's usage among three projects.

Expert Analysis

What the question is really asking

The stem is not asking for a general cost report. It fixes the scope: one Microsoft Foundry resource, three projects for separate business units, and shared Azure OpenAI model deployments. The view must split that shared model spend by project, remain reconcilable in Microsoft Cost Management, and avoid manual tagging. Those last two constraints are the discriminating tests.

Why B survives the constraints

B keeps Cost Analysis on the Foundry resource, groups by Resource, and saves a view per project. That uses native Cost Management records and built-in saved views, so business units can reopen consistent project breakdowns without creating and maintaining a project tag on every charge. This best matches 'Minimize manual tagging' while preserving a Cost Management-reconcilable view.

Why the other options fail

A scopes to the resource group and groups by Meter, then exports per project. Meter shows the model or usage meter, not the business-unit project; exports do not by themselves create a reconciled project view. C is the tempting distractor: a tag filter on project looks like chargeback, but it depends on manually tagging usage. A reviewer's point is exactly this: tags require maintenance, and a shared Foundry account's usage cannot be assumed to carry a per-project tag that splits three projects. That violates the minimize-tagging requirement. D scopes to the subscription and filters by Service tier: Azure OpenAI, then adds budgets per business unit. Budgets are alert thresholds, not an allocation of shared spend, and the service filter still aggregates the three projects.

Verdict

B is the only option that uses the Foundry resource scope, native resource grouping and reusable saved views to separate shared model costs while keeping the data in Cost Management and avoiding a tag-heavy chargeback scheme.

Official Reference

Exam Strategy

When a cost question stresses 'shared resource' and 'minimize tagging,' first eliminate any option whose allocation depends on tags or budgets. Then check whether the proposed Cost Management scope and grouping actually produce a project-level dimension; grouping by Meter or filtering by service tier only re-slices model or service costs. Prefer native resource grouping plus saved views, because it preserves Cost Management reconciliation and avoids manual metadata. Apply the same elimination order to AI-500 cost-governance scenarios.

Frequently Asked Questions

Why is a project tag filter not the best choice for shared Foundry costs?

A tag filter depends on manually tagging chargeback data, which conflicts with the requirement to minimize manual tagging. It also cannot be assumed to split usage on a shared Foundry resource across three projects.

Does grouping by Meter separate Azure OpenAI spend by project?

No. Meter groups cost by model or usage meter such as tokens or deployment type, not by the business-unit project that generated the usage.

What is the role of saved views in the correct Cost Management approach?

Saved views let each project or business unit reopen the same Foundry-scoped Cost Analysis with the Resource grouping already applied, avoiding repeated manual filtering while keeping data reconcilable in Cost Management.

More AI-500 FAQ →

Community Votes

B
65%
C
24%
D
11%

65% of anonymous learners picked answer B. Votes are pick records left by other test-takers — they are not the verified answer.

Discussion 1 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 1

  1. ExamProAzure 👍 1 Answered B
    Why C Fails: C. Tag filter on project: This depends on tagging, which the requirement says to minimize. Tags on the shared account also can’t split its usage among three projects.

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

← Back to AI-500 Study Guide