The course teaches implement, provision and operate as three modules. They are one loop, and the leg almost everybody skips is the one that goes back to the start. This page follows a single requirement all the way round, then models what closing the loop is actually worth.
Implement Provision Operate Close the loop
One loop, not three modules
Ask most organisations to describe their cloud governance and you get three separate answers from three separate teams. A platform team built the foundation, once, at project inception. A delivery team provisions into it continuously. A security team operates on top of it reactively. Each leg works. The problem is what does not happen between them.
The requirement we follow on every tabNo S3 bucket in AnyCompany may be created without versioning enabled.
One sentence. Unambiguous, easy to agree to, the kind of thing that gets signed off in a meeting and then has to survive contact with an estate. Follow it round the loop and every leg turns out to own a different piece of making it true.
What an open loop feels like from the inside
Nothing about it looks broken. The Config rule fires reliably. Remediation works. The dashboard goes green again within the hour. Somebody produces a monthly report showing that fourteen unversioned buckets were detected and corrected, which reads as evidence the control is working.
Then next month it is fifteen. The month after, thirteen. The number never trends toward zero, because nothing in that cycle changes the reason buckets keep arriving unversioned. Remediation treats the resource; it does not touch the thing that produced the resource.
The tell is the shape of the number over time. A governance control that is working should make its own findings rarer. If the violation rate is flat, you are not operating a control — you are operating a cleanup service, and paying for it monthly, forever.
Implement owns the default
Whether a newly created account and a newly created resource start compliant without anyone choosing to. This is the leg that changes the arrival rate.
Provision owns the easy path
Whether the compliant route is also the fastest route. If it is not, people will find the other one, and no amount of detection fixes that.
Operate owns the truth
What is actually out there right now, including everything the other two legs missed. It is the only leg that can tell you the other two are failing.
The claim this page defends. Detection and remediation are necessary and not sufficient. The economic argument for the implement leg is not that it is more secure — it is that its cost is front-loaded and then approaches zero, while an open loop's cost is linear and permanent. The Close the loop tab models exactly that divergence.
Leg 1 of 3 — Implement
Turn the sentence into a mechanism
The output of this leg is not a document. If the requirement ends up as a paragraph in a standards wiki, you have not implemented anything — you have written down an intention and delegated compliance to everyone's memory. Implement means the requirement now exists as something the platform evaluates or applies on its own.
The requirement, at this legNo S3 bucket in AnyCompany may be created without versioning enabled.
Four decisions before you write anything
ScopeDoes this apply to the whole organisation, or only to some workloads? Versioning has a storage cost, so a blanket rule across every sandbox bucket is a defensible choice but not an obvious one. Decide whether this attaches at the root or at specific OUs — and remember that attaching high is easy to reason about while detaching later changes state in many places at once.
MechanismVersioning is a property of a bucket's resulting state, not something expressible as a condition on a single API call. So the check itself has to be detective. That does not mean implement has no role — it means implement's job is the default, not the refusal.
CarrierHow does it reach every account? A CloudFormation StackSet deploying the Config rule organisation-wide, so a new account gets it without an onboarding step somebody can skip. If it arrives by runbook, it will eventually not arrive.
OwnerWho signs off, and who gets told when it fires. A control with no named owner survives until the first inconvenient exception request. This is a governance decision, not a technical one, and skipping it is why controls quietly die.
What actually gets built
The account baseline
The Config rule is added to the baseline StackSet that lands in every account Control Tower vends. From this point, account number ninety arrives already evaluating the rule — nobody enables it, because nobody was asked to.
The OU attachment
The rule is scoped to the OUs that carry the obligation. If it is genuinely organisation-wide it attaches at the root and everything below inherits it, including OUs created next year.
The remediation document
A Systems Manager automation document that enables versioning on a named bucket. Built now, wired up in the operate leg — because writing the fix while you are calm is better than writing it during a finding review.
Note what implement does not do here. It does not make any existing bucket compliant, and it does not stop the next unversioned bucket from being created. It changes the default and it installs the machinery. Those are different jobs from enforcement, and confusing them is how teams conclude the implement leg "didn't work".
Why this leg is supposed to run more than once
The single biggest misconception about implement is that it is a project phase. Something you do at the start, sign off, and move past. That framing is why the loop stays open: if implement only ever runs once, there is nowhere for what operations learns to go.
In a closed loop, implement runs every time the operate leg discovers something the baseline did not anticipate. A new resource type nobody scoped. A path into the estate that bypasses the catalogue. An OU that was created after the control was attached and never registered. Each of those is a finding whose correct destination is not a ticket to fix one resource, but a change to the mechanism.
Concretely, on our requirement: the first time operations reports unversioned buckets arriving from a CI pipeline that calls the API directly rather than launching a catalogue product, the fix is not to remediate those buckets. It is to go back to implement and decide whether that pipeline gets an approved product, a preventive control, or an exception with an owner and an expiry date.
Where this material lives in the course.M02 covers the landing zone, the account baseline, StackSets and the OU structure this leg depends on. The Landing Zone Builder lets you try the attachment decisions and see what changes.
Leg 2 of 3 — Provision
Make the compliant path the fast path
This leg has one job, and it is not enforcement. It is to arrange things so that the easiest way for a builder to get what they need also happens to satisfy the requirement. Get that right and compliance stops depending on anyone's diligence.
The requirement, at this legNo S3 bucket in AnyCompany may be created without versioning enabled.
The requirement becomes a template property
AnyCompany publishes an approved product — call it "Application data bucket" — in an AWS Service Catalog portfolio entitled to the delivery teams. The CloudFormation template behind it sets versioning on. Not as a parameter the launcher can choose; as a fixed property of the product.
That single design choice is what makes this leg powerful. A developer who wants a bucket opens the catalogue, launches the product, fills in the two or three parameters that are genuinely theirs to decide — name, retention class, cost-centre tag — and receives a bucket that is versioned, tagged and encrypted. They did not know versioning was a requirement. They did not need to.
Compare that with the alternative: a wiki page saying "remember to enable versioning". Same intent, wildly different compliance rate, and the difference is entirely about whether the requirement lives in a person's memory or in a template.
Decisions you take away
Versioning. Encryption at rest. Public-access block. Logging destination. The base tag set. None of these are exposed as parameters, because none of them are decisions the launcher is the right person to make. Every property you do not expose is a failure mode you have removed.
Decisions you leave
Bucket purpose and name. Lifecycle or retention class. The cost-centre and owner tags. Anything genuinely specific to this workload. Leaving these open is what keeps the product usable rather than a straitjacket people route around.
The design test for this leg. Time how long it takes a developer to get a compliant bucket through the catalogue, versus how long it takes them to create a non-compliant one by hand. If the catalogue is slower, you have built a control that loses to impatience — and it will lose quietly, at scale, without generating a single exception request.
The paths you did not catalogue
Here is the honest limit of this leg. A Service Catalog product governs the resources created through it. It has no opinion about anything else, and in a real organisation there is always something else:
A CI/CD pipeline that calls the S3 API directly using its own role, because it was built before the catalogue existed.
An infrastructure-as-code repository a team maintains themselves, deployed with their own credentials.
A third-party tool with an integration that provisions storage on your behalf.
Somebody in the console, doing something legitimate and urgent at four in the afternoon.
The management account, where a service control policy would not restrict them even if you had one.
Each of those produces buckets your product never touched. This is not a flaw in the catalogue model — it is the reason the third leg exists. Provision raises the compliance rate of the dominant path; operate finds out what the other paths did.
Making the fast path the only sensible path
Lever
What it does
Cost of using it
Publish the product
Gives builders a compliant option that is faster than building by hand. Raises the compliance rate on the path most people take.
Low. This is pure enablement — nobody loses anything.
Onboard the pipelines
Migrate the CI/CD paths onto the approved product or an approved module, so automation is governed too.
Moderate. Real engineering work per pipeline, and it needs a reason the owning team cares about.
Constrain the launch role
The launch constraint means the product deploys with permissions the consumer does not personally hold — so you can narrow the consumer's own direct permissions without blocking them.
Moderate. Requires knowing what each team legitimately does directly.
Attach a preventive control
Deny the direct path outright, leaving the catalogue as the only route. Strongest, and last.
High. Do this only after the catalogue genuinely covers the legitimate use cases, or you will drown in exceptions.
Order matters, and it is the reverse of most people's instinct. Publishing the product before restricting the alternatives means builders experience the catalogue as a shortcut. Restricting first means they experience it as a cage, and the first thing a caged team does is find or negotiate a way out. Same two actions, opposite outcomes, purely because of sequence.
Where this material lives in the course.M03 covers Service Catalog, portfolios, products, launch constraints and the administrator/consumer split. Lab 1 has you build the whole loop by hand, and the launch-constraint indirection is worth pausing on when you get there.
Leg 3 of 3 — Operate
Find out what actually happened
The first two legs are about intent and defaults. This leg is the only one that deals in facts. It tells you what is genuinely in the estate right now — including everything the baseline did not anticipate and the catalogue did not touch.
The requirement, at this legNo S3 bucket in AnyCompany may be created without versioning enabled.
Four things, in order
Detect
The Config rule evaluates recorded state
AWS Config records a configuration item whenever a bucket changes, and the managed rule S3_BUCKET_VERSIONING_ENABLED evaluates it. Scope it to AWS::S3::Bucket so you are not paying to evaluate resource types the rule cannot say anything about. The organisation aggregator in the audit account gives you one view across every account and Region rather than one console per account.
Alert
Somebody who can act finds out
The finding is routed — via EventBridge and SNS, or straight into your ticketing system — to a queue with an owner and an ageing report. This is the step that most often looks done and is not. A shared mailbox six people belong to has no owner, no state and no ageing, so a finding that lands there has changed who could know rather than who does.
Remediate
The Systems Manager document runs
An automation document enables versioning on the offending bucket. For this particular requirement automatic remediation is genuinely safe — turning versioning on breaks nothing and is reversible. That is not true of every remediation, and deciding which findings are safe to fix unattended is a real risk judgement rather than a maturity score. Lab 3 works through exactly that decision.
Feed back
Ask where the bucket came from
The step that closes the loop, and the step almost nobody builds. The resource is fixed — now find out what created it. Was it the catalogue product with a stale template? A pipeline nobody onboarded? A console action in an OU the rule was never attached to? The answer is a change to the implement leg, and making that change is what stops this finding recurring.
Fixing the resource versus fixing the cause
Two remediations look identical on a dashboard and are completely different operations.
Fix the resourceEnable versioning on anycompany-app-data-07. The finding clears. Cost: one automation run. Effect on next month: none whatsoever.
Fix the causeDiscover the buckets are coming from a deployment pipeline that predates the catalogue, and either onboard it onto the approved product or give it an approved module. Cost: real engineering work, once. Effect on next month: that source stops producing violations entirely.
Only the second one reduces future work. An organisation that only ever does the first is running a permanent cleanup service and calling it governance — which is exactly the divergence the next tab models.
The exposure window is real and it is not tunable to zero. Between the bucket being created unversioned and the rule evaluating it, the requirement is not being met. That interval depends on when Config records the configuration item and when evaluation triggers. If a requirement genuinely cannot tolerate any window, detection is the wrong primary mechanism and you need a preventive control — see Preventive vs Detective.
Where this material lives in the course.M04 covers Config, Systems Manager, GuardDuty and Security Hub in full. Lab 2 covers acting on groups of resources rather than individuals; Lab 3 covers rules and automated remediation.
What closing the loop is worth
Run the same requirement through repeated provisioning cycles under two regimes. Both detect every violation. Both remediate every violation. The only difference is whether each finding also causes a change to the implement leg. Watch what happens to the violation rate.
This is a model, not a measurement. The numbers are illustrative and generated by a simple decay rule — they are not drawn from any real environment and should not be quoted as data. What the model is for is demonstrating the shape of the two curves, because that shape is the argument. Your real numbers will differ; the divergence will not.
40%
Cycle 0. Each cycle, AnyCompany provisions 20 new buckets. 40% of them arrive through paths the catalogue does not govern, so some fraction are unversioned. Press Run cycles and compare the two regimes.
Regime A — open loop
Detect and remediate. Every violation is found and fixed, and nothing changes about why they keep arriving.
cycle 1violations per cycle—
0Violations created
0Remediations run
—Latest cycle
Regime B — closed loop
Same detection, same remediation — plus each finding feeds back: the baseline is updated, the product template fixed, a source onboarded.
cycle 1violations per cycle—
0Violations created
0Remediations run
—Latest cycle
Read the two shapes, not the two totals
Open loop — flat, forever
The bars stay roughly level. Every cycle produces about as many violations as the last, because remediation never touches the source. Cumulative remediation cost grows linearly and never stops growing. There is no cycle at which you are finished, and no point at which the control has paid for itself — it is a subscription.
Closed loop — front-loaded, then quiet
The early bars look identical to Regime A, which is the honest part: closing the loop costs more up front and looks like no improvement for the first few cycles. Then each fed-back finding removes a source, the bars shrink, and remediation work tends toward zero. The cost is front-loaded and finite.
Turn the leak up and run it again. The intuitive assumption is that a leakier estate makes closing the loop harder and therefore less worthwhile. The model shows the opposite: the bigger the ungoverned share, the larger the gap between the two regimes, because there is more source to remove. Closing the loop matters most exactly where it feels most hopeless.
What the model deliberately leaves out
Being clear about this, because a tidy simulation invites more confidence than it earns:
Feedback is not free. Each fed-back finding is real engineering work — onboarding a pipeline, revising a template, negotiating with a team. The model treats it as instantaneous. In reality it competes with delivery for the same people.
Not every source can be removed. Some paths are genuinely necessary and will stay ungoverned, so the floor is rarely actually zero.
New sources appear. Reorganisations, acquisitions and new tooling all reintroduce leak. A closed loop is a practice, not a state you reach.
The decay is smooth here and lumpy in reality. Removing one large source can drop the rate sharply in a single cycle; several small ones may show no visible movement for months.
None of those undermine the shape. They just mean the real curve is noisier and the real floor is above zero — while still being far below a flat line.
Where organisations break the cycle
Six patterns, all common, all diagnosable from the outside. Each one has a symptom you can observe, a cause that is usually structural rather than technical, and a fix that is smaller than it looks.
1. Remediation as a permanent subscription
SymptomThe monthly compliance report shows a healthy number of violations detected and corrected. That number has been roughly the same for a year.
CauseRemediation is wired to fix the resource and nothing is wired to ask where the resource came from. The loop terminates at "dashboard is green again".
FixAdd one field to the finding workflow: source. Every remediated finding must record what created the resource. Once a month, take the most frequent source and remove it. You do not need to fix all of them — the distribution is usually heavily skewed toward two or three sources.
2. Findings with no owner
SymptomSecurity Hub is enabled, findings are flowing, and nobody can say how old the oldest open one is.
CauseFindings are delivered to a distribution list or a dashboard rather than into a work queue. Email has no state, no assignment and no ageing, so there is nothing to be accountable for.
FixRoute findings into whatever queue the team already works from, with automatic ticket creation. The value is not the ticket — it is that a ticket has an owner and an age, so "we have detection" becomes a claim you can check.
3. A catalogue nobody uses
SymptomThe platform team maintains a Service Catalog portfolio. Provisioning volume through it is a small fraction of resources actually being created.
CauseThe ungoverned path is faster, better documented by word of mouth, or simply what the existing pipelines already do. Nobody is being obstructive; the catalogue just lost on convenience.
FixTreat adoption as a product problem, not a compliance problem. Find out what the catalogue is missing that makes people go around it — usually a parameter they need that you did not expose, or a product that does not exist yet. Fix that before reaching for a preventive control, because restricting first converts a convenience gap into a political one.
4. Controls attached at the wrong level
SymptomA growing register of documented exceptions, most of them from teams that have nothing to do with the obligation the control exists for.
CauseThe control was attached at the root because that felt safer and simpler to operate, so every OU inherited an obligation only some of them carry.
FixMove it down to the OU that actually holds the scope. Before you do, work out exactly which accounts change state — detaching is riskier than attaching because it changes many places at once. If the exception register is long, that is the estate telling you the attachment point is wrong.
5. Implement ran once, at project inception
SymptomThe account baseline was last changed eighteen months ago. Operations has learned a great deal since then, none of which is reflected in what new accounts receive.
CauseImplement was treated as a phase of a project rather than a standing capability. The team that built it moved on and nobody inherited the baseline as an owned artefact.
FixGive the baseline an owner and a review cadence, and make "does this change the baseline?" an explicit question in finding review. A baseline that never changes in a growing estate is not stable — it is stale, and the gap widens every month.
6. Believing you are more governed than you are
SymptomSomebody states with confidence that a control is enforced. Checking reveals it was never enabled, or is attached to one OU out of six.
CauseUsually the strongly-recommended-controls trap: the name implies they are on, and only mandatory controls are enabled by default. Sometimes it is an OU created after the control was attached and never registered.
FixAudit which controls are actually active per OU, not which ones exist in the catalogue. Then make new-OU registration part of the OU creation process rather than something remembered afterwards. This is the cheapest item on the list and the most likely to surprise you.
What to take away
Implement, provision and operate are one loop. Three teams doing three legs without a feedback path is the normal state, and it is why the same violations recur.
Each leg owns something different. Implement owns the default. Provision owns whether the compliant path is the fast path. Operate owns the truth about what is actually there.
Fixing the resource is not fixing the cause. Both clear the finding; only one reduces next month's work.
Open-loop cost is linear and permanent. Closed-loop cost is front-loaded and finite. That is the economic argument for the implement leg, and it is stronger the leakier your estate is.
The diagnostic is the trend, not the total. A control that is working makes its own findings rarer. A flat violation rate means you are running a cleanup service.
Closing the loop is a practice, not a milestone. New sources of leak arrive continuously, so the feedback leg never finishes running.