SAP-C02 - Design Solutions for Organizational Complexity (26% of the exam) - Section 1.5

Determine cost optimisation and visibility strategies across an organisation using AWS Cost Explorer, AWS Budgets, purchasing options and an effective cost allocation tagging model.

Describe how AWS Cost Explorer, Savings Plans, Reserved Instances, and cost allocation tags work together to provide visibility and reduce spend across a multi-account organisation. Use AWS Compute Optimizer recommendations to rightsize compute and distinguish Savings Plans commitment types by flexibility and coverage.

AWS Cost ExplorerSavings PlansCost allocation tagsAWS Compute Optimizer

Practice question for this objective

Free sampleDesign Solutions for Organizational Complexitymedium

A financial services firm runs about 60 accounts under one AWS Organizations payer. Finance must report spend along business dimensions that no single tag captures cleanly: a Product P is split across several linked accounts, while one shared platform account hosts resources belonging to three different products that are distinguished only by a mix of account, service and existing tag values. Leadership wants a reusable grouping that maps the consolidated bill into named buckets like Product and Business Unit using rules over accounts, tags and services, so the same buckets appear consistently in Cost Explorer, AWS Budgets and the Cost and Usage Report. Which capability BEST delivers this reporting view with the least ongoing effort?

ARe-tag every resource across all 60 accounts with a single Product key and a Business Unit key, then activate those keys as cost allocation tags so the bill groups purely by the two new tags.
BMove each product's resources into its own dedicated account and use the per-linked-account view in Cost Explorer as the Product and Business Unit reporting buckets for finance.
CCreate AWS Cost Categories in the payer account that define named groups such as Product and Business Unit using rules over linked accounts, services and tag values, then group Cost Explorer, Budgets and the Cost and Usage Report by those categories. Correct
DExport the Cost and Usage Report to Amazon S3 and build an Amazon Athena view that classifies each line item into Product and Business Unit, accepting that Cost Explorer and Budgets will not share these groupings.

Use AWS Cost Categories to map consolidated spend into named business buckets from rules over accounts, services and tags, consistent across Cost Explorer, Budgets and the CUR. AWS Cost Categories build named groupings from rules that combine linked accounts, services, charge types and tag values, which is what an organisation needs when a product spans several accounts and a shared account hosts several products. Once defined in the payer account, the categories become a grouping and filter dimension that Cost Explorer, AWS Budgets and the Cost and Usage Report all share. Flat retagging cannot encode the account-and-tag logic, account splitting is disruptive, and an Athena view does not propagate to the other billing tools.

Why A is wrong: A single flat tag per dimension cannot express a product that is defined by a mix of account, service and other tags in a shared account, and retagging tens of thousands of resources organisation-wide is a large ongoing effort that Cost Categories avoids by encoding the same logic as rules.

Why B is wrong: Splitting the shared platform account into one account per product is hugely disruptive, breaks shared workloads, and still cannot represent a product whose resources legitimately span several accounts, whereas a rule-based category models these relationships without moving anything.

Why C is correct: Cost Categories let you define named buckets from rules that combine accounts, services and tag values, exactly fitting a product that spans accounts and a shared account split by tags, and once defined the categories appear as a consistent grouping dimension across Cost Explorer, Budgets and the Cost and Usage Report.

Why D is wrong: A bespoke Athena classification view is custom SQL to author and maintain and produces groupings that live only in Athena, so Cost Explorer and Budgets cannot use the same Product and Business Unit buckets, failing the consistent cross-tool requirement.

See more SAP-C02 practice questions, answers explained.

Exam traps in Design Solutions for Organizational Complexity

Answers that look right on this material and are not. Each one is a distractor from a different question in the SAP-C02 bank for this domain.

Use AWS Budgets to set per-account spend thresholds that send alerts when EC2 costs rise, then have engineers manually shrink the instances that appear in the most expensive accounts each month.
Why it is wrong: AWS Budgets tracks and alerts on spend against thresholds but produces no utilisation analysis or instance-type recommendations, so it cannot tell the team which specific resources are over-provisioned.
Ask each account owner to apply business-unit tags by hand every month, then export the hourly Cost and Usage Report to Amazon S3 and build per-team views in Amazon QuickSight from the raw billing data files.
Why it is wrong: Manual monthly tagging plus a custom QuickSight pipeline is tempting for flexibility, but it is high-effort, error-prone and does not make new resources reportable automatically, which is the opposite of what leadership asked for.
Build a scheduled Lambda function that queries the Cost Explorer API daily, compares each tag group against a stored limit, and publishes Amazon SNS notifications to owners whenever a threshold is exceeded.
Why it is wrong: A custom Lambda and Cost Explorer polling job could replicate the behaviour, but it directly breaks the no-custom-code requirement and reinvents alerting that AWS Budgets already provides natively across the organisation.

Examworthy is not affiliated with or endorsed by Amazon Web Services. Original, blueprint-aligned practice material only.