Cloud Change Management Lab

A browser-based training lab where you act as the change manager for a fictional card-payments processor. Over three cloud changes you classify the change, assess risk, choose approvers, plan testing, rollback, the window, communications and verification, and then see a seeded outcome of what happened. It trains judgement about process weight, not console clicks.

In ITIL change enablement terms, a standard change is pre-authorised and follows a documented procedure, for example an allow-list edit that goes through the pipeline with a reviewed plan. A normal change is assessed and authorised before it is scheduled, for example tightening a production IAM role. An emergency change is needed urgently to stop active or imminent harm. A launch date or an impatient requester does not make a change an emergency.

A plan lists everything the pipeline will change, not just the line you wrote. If someone edited a resource by hand in the console, the plan can show the apply deleting it. Reading the full output is how a standard change stays safe, and the post-change plan shows whether drift remains.

An access report only covers its look-back window. A job that runs quarterly, yearly or only during an incident will not appear in a 30-day report, so removing its permissions looks safe until the job runs. A longer log replay, a scheduled-job inventory and a policy simulator are the evidence that closes that gap.

The key policy is the authority over who can use and administer the key. A policy that removes every administrator can leave the key unmanageable without the cloud provider's help, and a policy that trusts a whole account lets every role in it decrypt. Testing on a copy key and keeping a separate break-glass administrator are the safeguards.

A good rollback is a known-good state that has been tried. In these changes that means a revert commit through the same pipeline, a saved policy version with a one-step revert, or a saved key policy with a break-glass administrator outside the change. A plan to edit it back by hand is a hope.

Each change hides a few risks, such as a console-edited rule, a quarterly job or a lockout. The seed fixes the dice. Choosing tests, rollback, windows and approvers that address a risk makes it much less likely to fire, and a good rollback or verification limits the damage if it does. The same seed, level and plan always give the same outcome.

Rookie shows a hint at each step and a "watch for" list of hidden dependencies, and has the lowest chance that an unmitigated risk fires. Pro hides the hints, but a good test plan reveals a hidden dependency as you choose it. Elite hides everything until the outcome and raises the chance that an unmitigated risk fires.

A Markdown change record per change, with type, risk, approvers, window, test, rollback, communications, verification, the simulated outcome and the process findings, and a CSV register of all three. Downloading and copying documents is Pro. You can read the same records on the debrief page.

No. Tarnbrook Payments, its people, accounts and the tarnbrook.example domain are invented, any IP range is from the RFC 5737 documentation space, and every outcome is simulated in your browser. Nothing here connects to a real cloud account.