How it plays

Every stage is one of 18 game types

In every type you build or tune a design, run it, and the simulator shows where it stops and why: the hop, the rule, the meter that broke, with the concept and an exam tip. Hints start gentle and get more specific; the recap reviews your design the way an exam marks it. Here is each type's first stage, step by step.

Build it, then send traffic

23 stages

Network build

Build a VPC on the map so traffic reaches what it must and nothing else. The simulator follows every packet hop by hop and stops it where AWS would drop it.

Stages of this type: 20 in Networking, 1 in AI and machine learning, 1 in Data engineering and 1 in Core architecture.

Play a free one

Step 1 of 5

Read the mission brief

Open Brief on the rail. It names the VPC, its subnets and what must and must not connect. Each requirement is a check in the dock under the map.

Step 2 of 5

Build from the Palette

Open Palette and drag a component onto the map: a gateway onto the VPC, an instance into a subnet. Resources lists everything already there; click an item, in the list or on the map, to inspect it.

Step 3 of 5

Edit routes and rules

Select a route table, security group or network ACL and the Inspector opens it. Most fixes are one route or one rule.

Step 4 of 5

Predict, then follow the packet

Before the traffic goes, the dock asks where check 1 will stop; pick a station, or send it anyway. Then Next hop (or Play) walks each packet along the map, and it stops at the first thing that refuses it.

Step 5 of 5

Read the Debrief

Each failed check says where it stopped and why, with the concept and an exam tip. Get a hint climbs four rungs: where it stopped, why, the question that decides the fix, then the answer.

58 stages

Solution board

Fill each row with the right services. Records run from the source to what needs them, and each service takes only what its API accepts.

Stages of this type: 23 in AI and machine learning, 4 in Data engineering, 10 in Security, 17 in Core architecture and 4 in Operations and delivery.

Play a free one

Step 1 of 5

Read the rows

Each row starts at a SOURCE, passes through empty slots and ends at what it NEEDS. The source says what its records are: audio, a document, an event.

Step 2 of 5

Drop services into slots

Drag a service from Components into a slot on its row, or click it and pick the slot. A service that cannot take the row's records says so when it runs.

Step 3 of 5

Set each service

Select a placed tile to set it in the Inspector: a model, a mode, the option a requirement depends on.

Step 4 of 5

Run the rows

Running the board sends records along every row, one row at a time. A record stops at the tile that cannot handle it.

Step 5 of 5

Read the Debrief

Each failed row names the tile that stopped it and why, and Why not the others explains the services you did not pick.

3 stages

Edge security

Protect an application at its edge: the CDN in front of it, its web firewall, DDoS protection and the bucket behind it.

Stages of this type: 3 in Security.

Front Door

Step 1 of 5

Read who must get in

The brief lists who must reach the application and what must be kept out. Each one is a check under the scene.

Step 2 of 5

Pick what to change

There is nothing to place: select the distribution, the load balancer or a bucket in Resources.

Step 3 of 5

Change its settings

The Inspector edits the edge: origin access, cache behaviors and headers, the web ACL's rules and their order, geographic restrictions, the bucket's policy.

Step 4 of 5

Send traffic

Each request flies from the internet through the edge to the origin, and stops where the edge refuses it.

Step 5 of 5

Read the Debrief

Each failed check says where it stopped and why, with the concept and an exam tip. Change the design and run again; Get a hint starts gentle and gets more specific.

1 stage

Wire

Decide where each connection's encryption starts and ends: listeners, certificates and security policies on the way from client to data.

Stages of this type: 1 in Security.

On the Wire

Step 1 of 5

Read each link

The brief walks the connections one by one: a browser to a load balancer, an app to an API, nodes to each other, a laptop over VPN.

Step 2 of 5

Select where it terminates

Select a load balancer, a bucket, a cluster or the VPN in Resources. There is nothing to place.

Step 3 of 5

Set the protocol and certificate

In the Inspector: the listener's protocol and security policy, the certificate (public from ACM, private from Private CA), a policy that refuses plain HTTP.

Step 4 of 5

Send traffic

Each check follows one connection and stops where it travels in the clear or meets a certificate its client does not trust.

Step 5 of 5

Read the Debrief

Each failed check says where it stopped and why, with the concept and an exam tip. Change the design and run again; Get a hint starts gentle and gets more specific.

Tune it against a meter

13 stages

Lake tuner

Tune a data lake's tables so every query stays inside its limit and storage inside its budget. The Tuner's meters do the arithmetic as you change a setting.

Stages of this type: 13 in Data engineering.

Play a free one

Step 1 of 4

Find the tables

Components lists Tables in this lake, with each table's format, files and partitions. There is nothing to place.

Step 2 of 4

Tune in the Lake Tuner

Select a table to open the Tuner in the Inspector: format, compression, file size, partitions, lifecycle. Its meters show the bytes each query reads and what that costs.

Step 3 of 4

Run checks

Run checks runs each query and the month's storage against their limits, one row each.

Step 4 of 4

Read the arithmetic

A failed check shows the sum that broke the limit, such as 1,200 GB scanned against a 50 GB limit, and the setting that would change it.

2 stages

Sizing tuner

Size volumes, instances and tables so every workload gets what it needs, at the lowest bill. The Tuner shows the arithmetic behind each size.

Stages of this type: 2 in Core architecture.

Play a free one

Step 1 of 4

Find what to size

Components lists Things to size (or Tables to size): each volume or table with its type and size now.

Step 2 of 4

Size it in the Tuner

Select one to open the Tuner in the Inspector. Change the type, size, IOPS or capacity; the meter shows what that gives, such as 3 IOPS per GiB × 50 GiB = 150.

Step 3 of 4

Run checks

Each row runs its workload against what you sized: a volume that is too slow, too small or throttled fails its row.

Step 4 of 4

Mind the bill

The Debrief adds up the month's cost against the budget: the cheapest size that passes every row is the answer.

3 stages

Warehouse

Shape a data warehouse's loads, unloads and tables so the cluster's slices share the work and reads stay inside their share.

Stages of this type: 3 in Data engineering.

Load It Right

Step 1 of 4

Find the warehouse's parts

Components lists the warehouse's parts under In this warehouse: each load, unload and table with its files and format.

Step 2 of 4

Change how it loads

Select one to change it in the Inspector: the number and size of files, the format, a table's distribution and sort keys, a COPY's READRATIO.

Step 3 of 4

Run checks and watch the slices

Each row runs one load or query. The cluster behind the rows lights the slices that worked: one busy slice of 16 means the others waited.

Step 4 of 4

Read the Debrief

The Debrief names the number that decided, such as one gzip file of 310 GB that only one slice can read, and the change that spreads it.

1 stage

Cost meter

Cut the month's bill without breaking a requirement. The meter shows the bill against the budget at every change.

Stages of this type: 1 in Core architecture.

Pay Less, Size Right

Step 1 of 4

Read the bill

The month's bill sits under the scene: the total against the budget, each step's change, the commitment coverage and the cost by instance type.

Step 2 of 4

Place and resize

Drop cost tools from Components into the rows (a budget, a commitment, a report) and resize what the rows hold in the Inspector.

Step 3 of 4

Run checks

Each row is a requirement the cheaper design must still meet: the fleet still fits, the analyst still sees the line items.

Step 4 of 4

End at or under the model

The last check compares the bill with the best design's. The Debrief names the line that still costs too much.

Play it on a clock

5 stages

Stream clock

Key and size a stream so every write is accepted through its peak and records stay in order. The lab clock plays every second.

Stages of this type: 5 in Data engineering.

Hot Shard

Step 1 of 4

Read the lab clock

Under the scene, the Lab clock shows each shard's load second by second. A shard over its limit is red before you run anything.

Step 2 of 4

Change the lab's parts

Components lists Parts in this lab. Select one to set it in the Inspector: the partition key, the capacity mode, the shard count.

Step 3 of 4

Run checks

Run checks plays the clock through the peak; a check fails at the second a shard rejects a write or a record arrives out of order.

Step 4 of 4

Jump to the second

The Debrief gives the arithmetic (4,400 ÷ 4 = 1,100 a shard, over 1,000) and a button that shows that second on the lab clock.

6 stages

Fleet clock

Choose how a database and its clients fail over, then play the outage second by second on the Fleet Clock.

Stages of this type: 6 in Core architecture.

Survive the Zone

Step 1 of 4

Change the deployment

Components lists Parts on the clock. Select one to change it in the Inspector: a single instance or Multi-AZ, a read replica, RDS Proxy.

Step 2 of 4

Run checks

Run checks plays the day: the zone is lost at its second, and each requirement reads when writes, reads and connections came back.

Step 3 of 4

Play the Fleet Clock

Its meters (writes, reads, disk, the zone, DNS) show the outage as it happens; a mark on the slider is the second a check failed.

Step 4 of 4

Read the Debrief

Each failed check names the second and the count (reads unanswered for 420 seconds), and the cost line keeps the bill in sight.

2 stages

Alarm clock

Tune metric filters, periods and alarms so the right person is paged in time, and nobody is paged for nothing.

Stages of this type: 1 in Security and 1 in Operations and delivery.

Threshold Alarm

Step 1 of 4

Read the rows

Each row is an alarm chain: a source of events, a metric filter, an alarm, the action it takes. The checks say who must be paged, and how fast.

Step 2 of 4

Tune the chain

Select a filter or an alarm to set it in the Inspector: the pattern, the period, M of N datapoints, the action. Components holds what a row is missing.

Step 3 of 4

Play the Alarm clock

The run plays the day minute by minute: each alarm's datapoints, its state, and a mark where a page was sent or a check failed.

Step 4 of 4

Read the Debrief

A late page says why: a 300-second period waits for the period to close. The exam tip names the setting the question is about.

1 stage

Container clock

Set how containers and their nodes scale so every request is served through the morning's load, without paying for idle capacity.

Stages of this type: 1 in Core architecture.

Containers That Scale

Step 1 of 4

Select a service

There is nothing to place: select a service on the board or in Resources to change it in the Inspector, such as the task count, the scaling policy or the capacity provider.

Step 2 of 4

Run checks

Run checks plays the morning: requests rise, tasks start, nodes join. A check fails at the second requests go unserved.

Step 3 of 4

Play the Scaling clock

Its meters show requests not served, tasks provisioning, tasks against the floor and pods pending; marks on the slider show where checks failed.

Step 4 of 4

Read the Debrief

It gives the arithmetic at the second it broke: 400 requests a second at 80 a task need 5 tasks, and the service holds 4.

Decide who gets in

11 stages

Policy stepper

Edit identity, resource and key policies so each principal can do what it must and nothing more. The access matrix shows the gate that decided.

Stages of this type: 11 in Security.

Play a free one

Step 1 of 4

Find the policies

Components lists Policies and principals: the roles, the bucket, the key, the secret. There is nothing to place.

Step 2 of 4

Edit a statement

Select one to edit its statements in the Inspector: effect, actions, resources, conditions. A statement is added only once it is complete.

Step 3 of 4

Run the requests

Each check is one request, run through the IAM evaluation order: an explicit deny wins, then each policy type must allow it.

Step 4 of 4

Read the Access matrix

It opens after the run: one row per principal, a column per gate (SCP, resource, identity, boundary, session) and the exact error AWS returns.

5 stages

Lake access

Grant a governed data lake so each principal sees the columns and rows it should, and nothing it should not.

Stages of this type: 5 in Data engineering.

Who Holds the Keys

Step 1 of 4

Find the lake's permissions

Components lists Lake permissions: Lake Formation's settings, its grants and data filters, the bucket and the roles.

Step 2 of 4

Change a grant

Select one to change it in the Inspector: Lake Formation's defaults, a grant on a table or its columns, a data filter, the bucket's encryption.

Step 3 of 4

Run checks

Each check is one principal's query. It passes only when the principal gets exactly the cells the requirement names.

Step 4 of 4

Read the Access matrix

A grid of the cells each principal got (visible, leaked, missing, hidden), with the gate trace through IAM, Lake Formation, S3 and KMS.

3 stages

Organization tree

Set controls on an organization's tree so every account gets the guardrails it needs, from the root down to each account.

Stages of this type: 3 in Security.

Landing Zone

Step 1 of 4

Read the tree

The board stands on the organization: the root, its OUs and their accounts. The checks say what each account must and must not be able to do.

Step 2 of 4

Place controls

Drag a control from Components into a row's slot: a Control Tower control, a deny policy, a delegated administrator.

Step 3 of 4

Run checks

Each request runs through the organization's policies first, level by level, then the account's own.

Step 4 of 4

Read the Access matrix

It shows the SCP and RCP gates beside the account's own, the level that decided, and that an SCP never grants a permission.

Investigate and respond

4 stages

Network detective

A network that already fails. Each failed check is a ticket that shows only what the client saw; the Evidence tab holds the cause, and the cause is revealed once you have read the evidence.

Stages of this type: 4 in Networking.

Flight Recorder

Step 1 of 5

Send traffic as you find it

Run the checks on the network as it is. The dock asks where check 1 will stop; a guess is optional. A failed check says only what the client saw: a timeout, a refused connection.

Step 2 of 5

Turn on the evidence

Open Palette and drop a flow log on the VPC, a subnet or an instance (Resources finds the one you want), then send traffic again so it records.

Step 3 of 5

Open a ticket

Each failed check is a ticket in the Debrief tab, with the client's view and nothing else. Investigate opens the Evidence tab on the view that holds its cause.

Step 4 of 5

Read the evidence

The Evidence tab lists flow log records, analyzer paths and connection status. Find the record that names the cause, such as one REJECT and nothing after it.

Step 5 of 5

Fix it, then reveal

Change the rule or route the evidence points at in the Inspector. Reveal the cause works once the evidence has been read; after the first hint, Show the cause anyway skips the reading.

22 stages

Evidence desk

Each ticket is what a user reported. Find its cause in the evidence (logs, metrics, traces, findings) before you reveal it.

Stages of this type: 6 in AI and machine learning, 5 in Data engineering, 4 in Security, 6 in Core architecture and 1 in Operations and delivery.

Guard the Gate

Step 1 of 4

Run the checks

Each failed check is a ticket in the reporter's words: slow on the 30th, 503 on uploads, a backup that failed.

Step 2 of 4

Investigate

Investigate opens the Evidence panel. Its tabs are console tables (metrics, job history, CloudTrail, findings); the deciding number is in one of them.

Step 3 of 4

Fix what the evidence names

Change the setting in the Inspector, or place what was missing from Components, such as a log that was never turned on.

Step 4 of 4

Reveal only when you know

Reveal the cause turns a ticket into a plain explanation. Hint 2 names the evidence to open, if you are stuck.

5 stages

Runbook

Respond to an incident by putting the right steps in the right order. The timeline shows how each step changes the incident, minute by minute.

Stages of this type: 3 in Security and 2 in Core architecture.

Contain the Instance

Step 1 of 4

Read the finding

The Runbook panel opens on what was reported, and the checks say how each track must end: memory captured, session cut, team notified.

Step 2 of 4

Order the steps

Add steps from the shelf, move them up or down, put the wrong ones back. Each step takes its minutes on the timeline.

Step 3 of 4

Run the runbook

Run the runbook plays the steps in order; each one lights the resource it acts on.

Step 4 of 4

Read the Timeline

One row per track, one column per step: the step that broke a track is marked, and the Debrief names it with its time.