Design the unit of decision
In a fictional group, three teams share networking and tooling but own different applications. An account-level report helps locate charges; it is not necessarily the ownership view management needs. Start by defining the service, owner, period, and included costs. Keep an explicit category for amounts awaiting allocation. At the committee, present the reconciled total, assigned portion, and unresolved portion. Record who will resolve each exception and by when. Do not use a cost-center reorganization to announce technical efficiency: changing which team pays does not establish changed consumption. This is an educational decision model, not an internal procedure from any bank.
Make classification verifiable
Resource tags, cost allocation tags, and Cost Categories rules have different roles. Check that required dimensions are active in reporting and available for the observed period. A tag applied today does not establish that the report being consulted already contains it. For a division spanning accounts, define rules representing the business without relocating workloads just to obtain a chart. If the total is EUR 120,000 and classified applications sum to EUR 96,000, the EUR 24,000 difference still needs explanation. Do not remove it from the denominator. Document shared-service treatment and ownership changes so that two teams can reproduce the same result.
Budget, timing, and commitment
A budget alert depends on billing data arriving and notification processing. It should not be presented as an immediate spending block. Define recipient, response time, permitted action, and the service impact of a possible suspension. Compare reports on the same basis: amortization, credits, support, taxes, period, and currency can change the displayed amount. In the exercise, a EUR 900 monthly compute reduction is accompanied by EUR 250 in transfer and EUR 150 in operations. Modeled recurring savings are EUR 500. Two months also incur EUR 600 per month in coexistence: the balance is EUR 100 additional cost each month. These original assumptions are neither AWS prices nor a real financial forecast.
Separate administrative and failure boundaries
Separate accounts support administrative separation but do not establish that every execution path is isolated. Draw a critical operation’s path and mark shared networking, identity, configuration, data, and integration dependencies. Then choose a specific failure mode. If applications depend on one server in one AZ, account separation does not remove that common point. For a second Region, check whether required components remain accessible without the first. An application that starts but cannot obtain configuration has not restored service. Associate each assumption with evidence and an owner instead of accepting only the number of Regions or servers in a diagram.
Accept the integrated service
In the fictional daily-close case, each application passes its individual rehearsal. When all three recover together, the shared gateway saturates and the deadline is missed. The joint result takes precedence over the sum of isolated successes for that requirement. Record load, sequence, waiting time, and downstream completion evidence. Mitigation may involve additional capacity or business-approved sequencing, but it needs demonstration. Do not silently change the deadline in reporting. Reassess evidence after significant changes, particularly those introducing shared dependencies. An old rehearsal remains useful as a baseline; it does not automatically validate the current architecture.
Use the mock to guide review
This path’s mocks select original decisions already available in lessons and cases. The three forms share no questions, but learners who studied the bank may recognize items. After finishing, distinguish conceptual errors, missed constraints, and time management. Return to the lesson and explain why each alternative fails before repeating. Each form contains 75 questions and 180 continuous minutes, with explanations at the end. Every item contributes to DR accuracy; there is no conversion to an AWS scaled score. Editorial task mapping does not establish psychometric equivalence or exhaustive coverage. Summarize architecture decisions through requirement, assumption, evidence, and limitation: that habit helps both study and production meetings.
compute_saving = 900
extra_transfer = 250
extra_operations = 150
coexistence_per_month = 600
months = 2
steady_saving = compute_saving - extra_transfer - extra_operations
transition_saving = months * (steady_saving - coexistence_per_month)
assert steady_saving == 500
assert transition_saving == -200
# Original bounded exercise; no AWS prices, taxes, discounting or other costs.A fictional daily close crosses three applications and one shared gateway. Isolated rehearsals pass; simultaneous recovery fails on capacity.
Common pitfalls
Confusing alerts with hard caps, allocation with savings, accounts with physical isolation, and server startup with service recovery.
Related topics: Cross-account governance · FinOps and recovery
A verifiable decision keeps total cost, the business requirement, and dependencies visible, including what remains unproven.
Reference: Cost allocation tags · SAP-C02