Step 5 — Cost & Governance

Here’s a question worth sitting with before you open the exam guide: who in your organization actually knows what a single feature costs, once its compute spans four accounts, three Regions, and a shared RDS cluster billed to a fifth account entirely? At small scale, cost tracking is a spreadsheet. At the scale this exam assumes — dozens to hundreds of linked accounts — cost visibility has to be engineered as deliberately as the workload itself. This closing step covers that engineering, plus a candid look at how the exam itself is structured so your last few days of prep go toward the right things.

Cost Allocation That Survives an Org of 200 Accounts

Tags are the raw material of cost attribution, but tags alone don’t answer “how much did the Payments product line cost us last quarter” when Payments spans twelve accounts and shares a networking bill with four other product lines. AWS Organizations gives you three tools that build on each other rather than compete:

Cost Categories is the one Associate-level material never covers and Professional-level scenarios lean on constantly. It lets you define rules — “any account in the Payments OU, or any resource tagged product:payments, belongs to the Payments category” — and then Cost Explorer and Cost and Usage Reports can group by that category regardless of which account or which tag actually produced the spend. This solves the shared-cost problem: a shared Transit Gateway or a shared RDS cluster can be split by a percentage rule across categories, so “what did Payments really cost including its share of shared infrastructure” has an actual answer instead of a shrug.

Anomaly Detection matters at this scale because a human staring at a dashboard cannot catch a $40,000/month spend spike buried inside a$2 million/month total bill. It builds a spend baseline per service/account/category and alerts when actual spend deviates from the expected pattern — this is the tested contrast against a static AWS Budget, which only tells you when you’ve crossed a fixed number you chose in advance. A scenario describing “catch unexpected spend increases before they show up on the monthly bill, without setting a fixed threshold” is describing Anomaly Detection specifically, not Budgets.

Savings Plans and Reserved Instance Portfolio Management

At Associate level, Reserved Instances and Savings Plans are things you buy for a workload. At Professional level, they’re a portfolio you manage across an entire Organization, and the central lever is consolidated billing combined with Savings Plans/RI sharing.

Management Account (purchases Compute Savings Plan)
        │
        │  discount automatically applies across the whole Organization
        │
   ┌────┴─────┬──────────────┬──────────────┐
   │          │              │              │
Account A  Account B     Account C      Account D
(EC2)      (Fargate)     (Lambda)       (unused EC2 capacity
                                         still gets the discount
                                         applied to on-demand usage)

Because commitment-based discounts apply at the Organization payer level by default, a Compute Savings Plan purchased once in the management account discounts eligible usage anywhere in the Org — you don’t buy a separate plan per account. This is the mechanism behind portfolio-level cost governance: a central FinOps function purchases commitments based on aggregate historical usage across the whole estate, rather than every team independently guessing at their own future usage and under- or over-committing.

The decision between Savings Plans and Reserved Instances comes down to flexibility versus specificity:

A mature portfolio typically ladders commitment terms — some 1-year, some 3-year, staggered rather than purchased all at once — so the organization isn’t fully locked in at a single point in time and can adjust as workload patterns shift. Exam scenarios describing “usage patterns are still evolving” or “workloads span EC2, Fargate, and Lambda” point toward Compute Savings Plans; scenarios describing “stable workload, want to resell excess capacity if requirements change” point toward Standard Reserved Instances specifically, because that resale option doesn’t exist for Savings Plans.

Enforcing Tagging at Scale

A tagging strategy that exists only as a wiki page gets ignored within a quarter. The tested enforcement mechanisms build in layers:

Layer 1 — Prevent untagged resources from being created at all
   SCP: deny ec2:RunInstances unless request includes tag "cost-center"

Layer 2 — Detect resources that slipped through anyway
   AWS Config rule: required-tags, flags non-compliant resources

Layer 3 — Standardize the tag vocabulary itself
   Tag Policies (Organizations): defines allowed keys/values,
   prevents "Cost-Center" vs "costcenter" vs "CostCtr" drift

Tag Policies solve a subtler problem than the SCP layer does — even with a hard requirement to tag everything, without a Tag Policy you end up with a dozen inconsistent spellings of the same conceptual tag, each of which Cost Explorer treats as a separate value. The exam sometimes frames this as “cost reports show fragmented, inconsistent categories despite mandatory tagging” — that’s the signature of missing Tag Policies, not missing SCPs. You need both: the SCP forces a tag to exist, the Tag Policy forces it to be spelled consistently.

SAP-C02 Exam Domains and Realistic Weighting

The exam blueprint groups questions into four domains. Treat these percentages as directional, not exact — AWS updates them periodically, but the relative emphasis has held roughly steady across recent exam versions:

Notice cost and governance aren’t a standalone domain — they’re woven through all four, which is exactly why this step exists as a synthesis rather than an isolated topic. A migration question can just as easily be graded on whether your answer accounts for Reserved Instance implications as on whether you picked the right migration tool.

Study Tips and Common Traps at This Level

The single biggest adjustment coming from Associate-level prep: stop looking for the “correct” service and start looking for the “best fit given every stated constraint,” because Professional-level questions are deliberately written so that two or three answer choices are technically valid AWS architectures — the wrong ones just violate a constraint buried in the second sentence of the scenario (a compliance requirement, a stated budget ceiling, an existing tooling investment, a stated RTO/RPO).

A few traps worth naming directly because they recur across practice exams and real sittings:

• The “most secure” answer isn’t always correct if the scenario prioritizes cost or speed explicitly — read for what the business actually asked for, not what sounds most rigorous
• Distractors that solve yesterday’s problem — an answer that would have been correct on the Associate exam (single-account thinking, single-Region thinking) shows up as a wrong answer specifically because it ignores the organizational or multi-Region scale stated in the question
• Overlooking a stated existing investment — if the scenario says the company already has Terraform, or already runs on-prem VMware, the “textbook best” answer that ignores that existing tooling is usually the trap
• Treating RTO/RPO numbers as flavor text — a stated RTO of minutes eliminates backup-and-restore DR strategies immediately; a stated RPO of near-zero eliminates anything relying on periodic snapshots
• Assuming SCPs or Config rules apply where they structurally can’t — remembering that SCPs never touch the management account is a small fact that resolves several otherwise-confusing governance questions

Budget your final study days toward scenario practice over flashcard memorization — this exam rewards pattern recognition across long scenario paragraphs far more than recall of individual service facts, and that skill only builds by working through full-length scenarios under time pressure, not by re-reading service documentation one more time.

Exam Focus: What Questions Test From This Step

• Cost Categories versus Cost Allocation Tags — aggregating shared and cross-account spend versus per-resource tracking
• Anomaly Detection versus static Budgets — statistical deviation alerting versus fixed-threshold alerting
• Savings Plans applying automatically across an Organization’s payer account versus per-account RI purchases
• Choosing Compute Savings Plans (flexible, evolving compute mix) versus Standard Reserved Instances (stable workload, resale option)
• Layered tagging enforcement: SCPs (existence), Config rules (detection), Tag Policies (vocabulary consistency)
• Recognizing which domain weighting deserves more practice time in final review
• Spotting constraint-driven distractors: compliance, existing tooling investment, and stated RTO/RPO values that eliminate otherwise-valid answers
• Applying multi-account and multi-Region thinking by default, rather than defaulting to single-account Associate-level patterns