Break it on purpose: watch the platform answer Start this lab

Why this matters

You learn what a failing platform looks like far faster by causing it in a place where it does not matter than by waiting for it. Every change here has a number attached on both sides of it, so the shapes — wait time accelerating, memory leaving the guests, a path gone — become recognizable rather than theoretical.

Concepts

Objectives graded

• Record the healthy score and the healthy performance figures before you spoil anything.
• Make a change the platform should refuse and record exactly what it demands.
• Move one setting at a time, read the numbers, then put that setting back before the next experiment.
• Show that wait time rises faster than the ratio that causes it.
• Show that oversold memory is reclaimed from inside the guests before anything reaches swap.
• Put every change back and prove the baseline score returned.

MITRE ATT&CK coverage

Spoiling a platform deliberately teaches what resource exhaustion looks like from the console, so the same shape arriving unannounced — wait time climbing, memory reclaimed, a path gone — is recognized as a symptom to be traced rather than a mystery.

What each rubric rule proves

• The workflow reached a terminal success state on the graded run.

  behavior · weight 20

• A reversible action passed through a human approval gate.

  safety · weight 15

• No non-idempotent operation was retried without an idempotency key.

  efficiency · weight 10

• Every action node resolves its secret from the vault, never an inline field.

  configuration · weight 10

• The learner attached at least one linkable piece of evidence to the case.

  investigation · weight 10

• The case carries an analyst closure note explaining the outcome.

  explanation · weight 10

• No innocent asset in the alert batch was contained, disabled or revoked.

  behavior · weight 15

• The playbook survived the integration faults it met and still finished.

  configuration · weight 15

• Nothing was changed in the estate before evidence had been gathered.

  investigation · weight 10

• The platform was worked in the console rather than described from the ticket.

  investigation · weight 15

• The healthy state was recorded before anything was spoiled.

  investigation · weight 10 · T1082 System Information Discovery (Discovery)

• The platform's own guard rail was found by hitting it, not by reading about it.

  investigation · weight 10 · T1078 Valid Accounts (Defense Evasion)

• The change was made properly and the resulting ratio read off the host.

  configuration · weight 10 · T1082 System Information Discovery (Discovery)

• The effect on wait time was measured at the moment the cause changed.

  configuration · weight 10 · T1082 System Information Discovery (Discovery)

• One variable was changed at a time, so the memory reading means something.

  configuration · weight 10 · T1082 System Information Discovery (Discovery)

• The storage path was shown to matter with a number rather than an opinion.

  configuration · weight 10 · T1046 Network Service Discovery (Discovery)

• The cost of the critical check was measured in the score itself.

  configuration · weight 10 · T1082 System Information Discovery (Discovery)

Common mistakes

• Stacking several changes and then trying to attribute the result to one of them.
• Skipping the healthy reading, which leaves nothing to return to.
• Reading the refusal as a fault in the platform.
• Leaving the platform spoiled because the numbers were the interesting part.

Same idea, three vendors

Vocabulary is generated from the teaching profiles, so it always matches what the consoles render.

The same concepts in shipping products

The consoles you practice in use teaching names. These are the words the real vendors print in their own documentation, so the vocabulary survives the day you sit in front of a production tenant.