The previous four lessons have assembled the pieces separately: where the code lives, how it is built and tested, how it is deployed without taking the service down, and how it is all chained together. This lesson adds no new services. It takes a real change of Luis's and follows it from his laptop to production, step by step, seeing at each point what gets checked and what exactly happens if it fails.

The change was deliberately chosen not to be trivial. Sara has asked for a delivery time slot to be added to the order, and that touches four things at once: the shop's code, a consumer of cola-mercadofresco-pedidos, the Aurora schema and the contract of the PedidoConfirmado event. It is exactly the kind of change that caused an incident in module 7 — a producer deployed before its consumer — and that we are going to make here without anybody typing a command or crossing their fingers.

Cost warning. The full journey of this change — four pipeline executions across development, pre-production and production, plus the PR builds — costs around 0.60 USD. AppConfig, which turns up at the end, charges 0.0000002 USD per configuration request with a 60 s cache: for MercadoFresco, pennies a month. Fictitious data.

1. The change: delivery time slot
2. The full journey at a glance
3. Branch, commits and pull request
4. Build, tests and artefact
5. Schema compatibility: expand and contract in Aurora
6. Contract compatibility: versioning PedidoConfirmado
7. The right order between producer and consumer
8. Deployment to development, smoke tests and Marta's approval
9. Canary in production, monitoring and promotion
10. Configuration and secrets per environment
11. The test pyramid applied
12. DORA metrics: MercadoFresco before and after
13. Rollback runbook and the failure detected late
14. Small deployments and feature flags
15. Friday afternoon as a business decision
16. Module wrap-up and cost
17. Common mistakes and tips
18. Exercises
19. Conclusion

Sara backs it up with a figure: 31 % of delivery incidents are down to the customer not being in. Each one costs a second attempt, a phone call and, with fresh produce, sometimes the goods themselves. The request is to add three slots — manana, tarde, 24h — to the checkout flow.

What looks like a form field touches five pieces:

The two high risks are the heart of the lesson, and they share one property: they are the two things that CodeDeploy's automatic rollback cannot undo. Everything else goes back in ninety seconds.

Luis branches off desarrollo, following the model from 08-01, and holds himself to the three-day limit:

The commits, in the conventional format the pipeline will read later on:

The first feat determines that the version goes up to 1.6.0 — MINOR, compatible functionality. If any of them carried BREAKING CHANGE: in the body it would be 2.0.0, and that is precisely what we will avoid.

When he pushes the branch, the pull request trigger from 08-04 starts the pipeline in reduced mode: build, tests and quality, with no deployment stages. The result is published on the PR as a status check, and the PR cannot be merged while it is red. This is where the main protection left open in 08-01 is finally closed: it is not enough for somebody to approve the change, the build also has to be green before the merge button does anything.

PR #47 uses the template from 08-01, with one section that in this change is the most important of all:

Marta reviews and approves; Luis merges with squash, and the resulting commit lands on desarrollo.

On merge, the full pipeline starts. The build stage does what 08-02 described and produces mercadofresco-tienda-1.6.0-a3f9c21.zip, with the commit in its metadata.

This is the only thing that gets built in the whole journey. The same S3 object will be deployed to development, to pre-production and to production. If the pipeline rebuilt before production, Marta's approval would stop meaning anything, as we saw in exercise 1 of 08-04.

Applying the rule from 08-03, the schema change does not go in the same step as the code and is split into three phases separated in time.

Phase 1, EXPAND, in a pipeline stage of its own before any application deployment:

Those three comments are the whole exercise. With NOT NULL, the previous version would fail on every insert during the gradual deployment. With DEFAULT, PostgreSQL 11 and later do not rewrite the table, but earlier engines do, and over 4.2 million rows that is a lock lasting minutes. And the index is postponed because CREATE INDEX blocks writes: it will be done with CONCURRENTLY and outside the deployment.

Phase 2, MIGRATE, is the 1.6.0 code: it writes franja_entrega when present and tolerates NULL when not.

Phase 3, CONTRACT, three weeks later and as a change of its own, when no instance is serving 1.5.2 any more and it has been confirmed that every new order comes with a slot:

The automatic control that stops anyone skipping this is the migration analysis in CodeBuild that we designed in exercise 3 of 08-03: it fails the build if it finds DROP COLUMN, RENAME COLUMN, SET NOT NULL or DROP TABLE in a migration file without the -- CONTRACCION-APROBADA tag. Phase 3 carries it and phase 1 does not need it.

The other high risk. PedidoConfirmado is consumed by three targets of bus-mercadofresco: the warehouse queue, the analytics one and the partner's ERP API. Luis controls neither of the last two, and that is the problem: publishing a different event can break somebody you did not even know was listening.

Adding franja_entrega as an optional field is the easy case, and the event moves up to version 2:

A v1 consumer receives an object with a field it does not know about and ignores it, as long as it was written following the golden rule: be strict in what you publish and tolerant in what you receive. A consumer that validates the schema with additionalProperties: false would break, and that is why the contract test is blocking:

The two central tests are the second and the third, and it is worth understanding why both are needed. The second checks forward compatibility: the old consumer with the new event, which is what happens as soon as the shop starts publishing v2 and some consumer has still not been updated. The third checks backwards compatibility: the new consumer with the old event, which is what happens with the messages that were already in the queue when the consumer was deployed. During a gradual deployment both situations exist at the same time, and one test on its own only covers half of it.

For the partner's ERP, which cannot be tested, the safeguard is a different one: the EventBridge archive we turned on in 07-03. If the partner breaks, there are 90 days of events to replay.

This is where the incident left hanging in module 7 gets closed. The rule is short and holds for any contract change:

Always deploy the reader first, the writer second.

The reasoning is set theory. A new consumer understands the old events and the new ones — because we have tested it — so deploying it first is safe: during the window there are only old events, which it knows how to process. The other way round does not work: if the producer goes out first, there are v2 events travelling towards v1 consumers for as long as the deployment lasts, and it only takes one of them validating strictly for messages to appear in mercadofresco-pedidos-fallidos.

In the pipeline this is a stage with two actions and a different runOrder, which is exactly the mechanism from 08-04:

runOrder: 1 for the consumer and 2 for the shop. The order stops depending on somebody remembering it: it is declared, versioned and executed the same way every single time. That is, in one sentence, the value of the whole of module 8.

In development the pipeline uses AllAtOnce, because speed matters more than availability. The smoke tests from 08-04 run against the freshly deployed environment and add two cases from this change:

The second test is the one that really matters: it verifies against a real environment that a customer with the old app on their phone can still buy. If it fails, the pipeline stops in development and nobody outside the team has noticed a thing.

At 10:42 the notification reaches alertas-mercadofresco and Slack:

Marta opens the diff, sees 214 lines in four files, checks that the migration is an expansion and approves. Forty seconds. Not out of blind trust, but because the message answers in advance the questions she would ask: what is going in, who did it, if it was tested, what does not revert and if the timing is right.

The production stage performs three coordinated deployments:

Throughout the process three alarms wired to the automatic rollback are watching: mercadofresco-alb-latencia-alta, mercadofresco-pedidos-fallidos and mercadofresco-cobrar-pago-errores-canario. And when it finishes, the quality gate from 08-04 watches the MercadoFresco/Tienda metrics for 15 minutes, with the window sized to fit inside the 30 minutes of terminationWaitTimeInMinutes — if the gate took longer, the blue environment would already have been terminated and the ninety-second rollback would have ceased to exist.

If all goes well, the pipeline finishes, CodeDeploy terminates the blue environment after 30 minutes and a final action tags the version:

What gets tagged is what reached production and survived the quality gate, not what was built. It is an important difference: the tag certifies a fact, not an intention.

If something fails, each mechanism acts within its own timeframe:

And the part that no mechanism rolls back: the franja_entrega column is still there. That is fine, because it is NULLABLE and 1.5.2 ignores it. That is exactly why the expansion phase is harmless: it turns an irreversible change into one that does not get in the way.

The artefact is the same in all three environments, so the difference between them cannot live in the package: it lives in the configuration read at start-up, with what we set up in 04-03.

The last row is the rule: if a value differs between environments, it has to be in Parameter Store. A value set by hand on an instance disappears with the next blue/green deployment — the instances are new — and comes back as an intermittent failure that is impossible to diagnose.

The shape of the pyramid is not decoration: the base is wide because the tests at the bottom are cheap, fast and precise, and the top is narrow because the ones up there are slow, expensive and brittle. A team with 200 end-to-end tests and 20 unit tests has a suite that takes an hour, fails intermittently and does not tell you where the problem is.

Contract tests are the level almost nobody has and the one this change proves necessary: they cost 15 seconds and they are the only thing that detects that a third-party consumer is about to break.

The four DORA metrics measure a team's delivery capability. MercadoFresco's, measured over the three months before module 8 and the two after it:

Three readings worth taking from these numbers, because figures on their own are misleading:

Frequency goes up because the marginal cost of deploying goes down. Before, deploying cost Luis an hour of work and a dose of nerves, so he piled changes up: "since I am deploying, let all four go out". Now it costs nothing, so he deploys as soon as something is ready. And that feeds back into the failure rate: a deployment of one change is far easier to diagnose than one of four.

Time to restore is the biggest improvement and the most important one. Going from 47 minutes to 4 is not a process improvement, it is a change of nature: 47 minutes of degraded shop on a Friday at 19:00 is around 700 affected orders; 4 minutes is around 60. And most of those 4 minutes is detection, not reaction, because the rollback itself takes ninety seconds.

The 7 % failure rate is not zero and should not be. A team with a 0 % failure rate is almost always deploying too little and too late. The goal is not to never fail, it is for failing to be cheap: for a failure to cost 4 minutes and not 47.

And a warning. DORA metrics are useful as a thermometer for the team and dangerous as an individual target: as soon as "deployment frequency" becomes a goal, empty deployments appear to push the number up. Measure them, watch the trend, and do not hang them on anybody's personal performance board.

The automatic mechanisms cover the first fifteen minutes. The hard case is the failure that shows up at 19:30 from a deployment at 11:00, when the blue environment no longer exists and the quality gate gave its approval hours ago.

This is the runbook, written to be followed at three in the morning:

1. Contain (0-5 min). Can it be switched off without deploying? If the change is behind a feature flag, turning it off is a matter of seconds and is always the first option. If not, disable the pipeline transition into production with disable-stage-transition so that nobody makes the situation worse while it is being diagnosed.

2. Decide the direction (5-10 min). It is the decision most often got wrong under pressure:

3. Execute (10-20 min). Backwards is a normal deployment of the previous version through the pipeline, using the artefact that is still in S3 with its predictable path — tienda/1.5.2-8b2e440/paquete.zip — which is what makes the rollback possible in a minute. It is the reason the bucket's lifecycle rule is 60 days and not 3.

4. Verify (20-30 min). /salud returns the expected version, TiempoConfirmacionPedido goes back to its normal band, PedidosConfirmados picks up its rhythm again, and the DLQ stops growing.

5. Recover the data, the step that gets forgotten and the one that leaves the most damage. The messages piled up in mercadofresco-pedidos-fallidos are processed with the DLQ runbook from 07-05 — contain, classify, fix, reprocess — never with a redrive before fixing the cause. And if the event had moved up a version, whatever was published during the incident is replayed from the EventBridge archive, always with FilterArns so as not to repeat effects that already happened.

6. Blameless post-mortem, within 48 hours. What happened, why the gates did not catch it and what new test would have caught it. That last point is the only mandatory deliverable: a post-mortem that does not produce a new test is a meeting.

Two practices that multiply the value of everything above.

Small, frequent deployments. This is not an aesthetic preference: it is the arithmetic of diagnosis. A deployment with one change has one suspect; one with six has fifteen possible pairs of interaction. MercadoFresco's rule is that a branch lives three days at most — from 08-01 — and that if a change does not fit, it gets split into backwards-compatible increments, exactly as this one has been split.

Feature flags with AWS AppConfig. They separate deploying from releasing: the code goes out to production switched off, and it gets switched on when and for whom it is decided.

With this in place, the checkout flow does if flag("franja_entrega_activa"): and Luis deploys on Tuesday with the flag off, switches it on for 10 % of customers on Wednesday, watches the metrics and reaches 100 % on Thursday. Deploying stops being the moment of risk.

The last row is the warning. A flag is temporary code with an expiry date: it has to go on the backlog the same day it is created and be deleted as soon as it is at 100 % and stable. A system with forty old flags has a state space nobody can reason about or test.

"No deploying on Fridays" is one of the most repeated rules in the industry, and almost always for the wrong reason. The usual reason is fear: we do not know what will happen and we do not want to be here to see it. That is not a policy, it is a symptom — that the pipeline does not inspire confidence, that the rollback has not been tested, that nobody knows how long going back takes.

With what MercadoFresco has now, the question can be answered with numbers:

MercadoFresco's rule is not "no deploying on Fridays", it is "no deploying to production between 16:00 and 22:00 on Fridays". And the reason is not fear: it is that the same incident costs five times more in that slot and there is a third of the team around to handle it. It is a business decision, taken with data, open to review if the data changes. Outside that slot Friday is deployed to like any other day, Thursday afternoon and Friday morning included.

And it is implemented as a control, not as a reminder: a transition disabled on a schedule, so that it does not depend on somebody remembering at 18:50.

The fourth problem of the course is solved. The module began with MercadoFresco's code sitting on a laptop, an scp over SSH on a Friday afternoon and no way of going back other than hunting down the previous file. It ends with a change that touches four systems travelling the complete path without anybody having to type a single command.

The complete chain, one sentence per link: 08-01 put the code in a repository with short branches, pull requests and protection on main. 08-02 turned every push into a clean build that tests, scans and produces an immutable artefact. 08-03 turned the deployment into a governed operation with hooks, gradual strategies and automatic rollback on alarm. 08-04 chained it all together into a pipeline with stages, informed approval and quality gates. And 08-05 has shown that the chain holds up under a real change, schema and contract included.

Twenty-eight dollars a month. The right comparison is not against zero: it is against a 47-minute median time to restore, 23 % of deployments failing and the hours Luis spent deploying by hand.

Deploying the producer before the consumer. It is the module 7 incident and the rule is a single sentence: the reader first, the writer second.

Putting the schema change in the same deployment as the code. The rollback rolls back artefacts, not databases.

An expansion migration with NOT NULL or with an index. It stops being harmless: it breaks the previous version or locks the table.

Testing only backwards compatibility. During a gradual deployment both directions exist at the same time; both tests are needed.

Removing or renaming a field of an event. It is not compatible even if the consumer "looks" tolerant. Add, publish both, wait, remove.

Rebuilding the artefact before production. It invalidates all the earlier tests and the approval.

Different configuration set by hand on an instance. It disappears with the next blue/green and comes back as an undiagnosable intermittent failure.

Feature flags that never get retired. Forty old flags are a state space nobody can test. Put it on the backlog the day you create it.

A flag that takes the shop down if AppConfig fails. The default value on error must always be the safe one.

Using DORA metrics as an individual target. Empty deployments appear and the metric stops measuring anything.

Redriving the DLQ before fixing the cause. The messages fail again and information is lost.

Tip: write the PR's "Risks" section before writing the code. If you do not know what risks your change carries, you have not designed it yet. And rehearse the rollback deliberately once a quarter, timing it: it is the only way for the number in the runbook to be true.

Tip: in the post-mortem, the mandatory deliverable is a new test. Without that, it is a meeting.

Tip: turn "we do not deploy on Fridays" into a window backed by data. A rule justified with numbers gets respected; one justified with fear gets skipped the day there is a rush.

Sara is now asking for something bigger: scheduled deliveries up to 7 days in advance, with an availability calendar per postcode, different prices depending on the day and a limit on orders per slot and zone. It touches the shop, the API, three new tables in Aurora, the warehouse consumer, the PedidoConfirmado event (which needs fecha_entrega as well as franja_entrega) and a new price calculation. Luis estimates three weeks.

Break it down into increments that respect the three-day-per-branch limit. For each one, say what gets deployed, what changes in the schema and in which phase, whether it needs a feature flag and what can be verified in production when it is done. Say explicitly which one comes first and why.

Tuesday, 11:00: 1.6.0 is deployed with everything green. At 19:30, Sara reports that on the mercadofresco-negocio dashboard orders with the tarde slot have dropped to zero since 17:00, while manana and 24h are normal. Total PedidosConfirmados is only 8 % below normal, no alarm has fired and the quality gate gave its approval at 11:20. The blue environment no longer exists.

Answer: (a) why no automatic mechanism detected it; (b) the first 15 minutes, in order; (c) in which direction to roll back and why, knowing the migration was an expansion; (d) what to do with the orders from those two and a half hours; (e) which three new controls would come out of the post-mortem.

MercadoFresco has had the pipeline for two months. Data from the last month: 19 deployments to production; a median lead time of 3 h 20 min, of which 2 h 40 min is waiting for Marta's approval; 2 deployments rolled back out of 19; a median time to restore of 4 min, but with one case of 95 minutes — the failure detected late. Marta wants to reach the elite category in all four metrics.

For each one: say where MercadoFresco is, what the elite target is, what concrete change you would propose and what risk that change carries. Say which one you would tackle first and justify it.

Solution 1

Six increments, each deployable and verifiable separately. The principle that orders them is that each increment must be useful or harmless on its own, never "half a feature halfway there".

The first is increment 1, and the reason is this lesson's rule: the schema change is the only thing that does not roll back with the code, so it goes on its own, in its own deployment, with nothing else that could fail and force a rollback. Three empty tables nobody queries are the safest change there is: if something goes wrong, there is nothing to undo. Putting them in the same deployment as the new code would be mixing irreversible risk with reversible risk, which is exactly what 08-03 warns against.

Two further observations. Increment 4 goes before 5 by the ordering rule: the consumer understands before the producer starts publishing. And increment 3 deploys the v3 event with the flag off, so that the field exists in the code but is not published until it is switched on: that gives a window to verify the consumers in production without anything really having changed.

Solution 2

(a) Because no alarm was measuring the dimension that failed. PedidosConfirmados is an aggregate, and an 8 % drop in the total is within the normal noise of a Tuesday; the latency alarm does not fire because the system is not slow, it is rejecting; the DLQ does not grow because there is probably no exception, just a validation returning a clean 400. And the quality gate did its job correctly at 11:20, six hours before the problem appeared: it was a time of day with little tarde traffic.

The underlying lesson is uncomfortable and holds for any system: automatic gates detect what they have been told to look at, in the window in which they look. A failure that only affects one segment and only shows up six hours later is invisible to them by construction. Sara detected it looking at a business dashboard, and that is not a failure of the system: it is the reason mercadofresco-negocio exists.

(b) The first 15 minutes. Contain: if franja_entrega is behind an AppConfig flag, switch it off — customers go back to the previous behaviour in seconds and the incident ends there. If not, disable the transition into production so that nobody deploys on top of it. Confirm: check in CloudWatch that the drop in tarde is real and not a dashboard problem, and look at the API logs filtering by requests with franja_entrega=tarde — most likely a systematic 400 or 422. Narrow it down: do all tarde orders fail or only some? From exactly 17:00? That it starts at 17:00 and not at 11:00 is the main clue: it suggests a time-dependent condition, for example a validation that rejects the tarde slot once its cut-off time has passed, with the time zone calculated wrongly. Notify: the team and Sara, with what is known and what is not.

(c) Backwards, to 1.5.2, if the flag does not exist or does not fix it. And it can be done without fear precisely because the migration was an expansion: the franja_entrega column is NULLABLE, 1.5.2 does not know about it and ignores it, so rolling the code back leaves the system exactly as it was before Tuesday. The orders from the last few hours keep their slot in the column, which will be recovered when the corrected version is deployed. If the migration had been a contraction, the answer would be the opposite — forwards, fixing — and with the shop degraded in the meantime: the expansion phase is what makes this decision an easy one.

(d) The orders from those two and a half hours. They are not in the DLQ, because they were probably never even created: they are customers who tried to choose tarde, saw an error and left. It is lost sales, not lost data, and it has to be treated as such: estimate the volume by comparing with the same slot on previous Tuesdays, and decide with Sara whether any commercial action is called for. If there were also orders created with the wrong slot assigned, they are identified by time range and corrected with a reviewed script, never with an improvised UPDATE in production. And if there are events that were not published, they are recovered from the EventBridge archive with FilterArns.

(e) Three controls from the post-mortem. One alarm per dimension, not just per aggregate: a PedidosConfirmados metric with a FranjaEntrega dimension and an alarm that fires if any slot drops to zero for 15 minutes during business hours. It is cheap and it would have warned at 17:15 instead of 19:30. A smoke test with a clock: cases that depend on the time of day have to be tested at different times, so a synthetic execution every hour with the three slots, or unit tests with a simulated clock covering the edges — and very much including the time zone, which is the suspect here. And extending the quality gate with a second, deferred evaluation: an automatic check 4 and 12 hours after the deployment that compares the metrics by dimension with the same period the week before and warns if anything has moved. It does not block the pipeline — that finished long ago — but it turns "Sara spotted it by chance" into "the system raised it".

Solution 3

Deployment frequency. MercadoFresco is at 19 a month, around 4.4 per week: category high. Elite is on demand, several times a day. The change: remove the manual approval — which is what imposes a daily rhythm on the whole thing — and batch fewer changes together. The risk: removing it before the quality gate is mature swaps a control for a hypothesis, and the exit conditions Marta wrote in 08-04 exist precisely for that.

Lead time. 3 h 20 min is high; elite is under an hour. And the diagnosis is served up on a plate: 2 h 40 min of the 3 h 20 is human waiting, so the technical pipeline already takes 40 minutes and is in the elite range. The change is not optimising the build: it is the approval. Two gradual measures before removing it altogether: approval from Slack with AWS Chatbot, which brings the wait down from hours to minutes because Marta does not need to be sitting at her computer, and a designated stand-in. The risk of the first is practically nil, and that is why it is the one to do right now.

Change failure rate. 2 out of 19 is 10.5 %: category medium-high; elite is below 15 %, so technically it is already there. But the number misleads if you do not look at the cases: one of the two failures was the 19:30 one, which no gate detected. The useful change is not lowering the percentage, it is improving detection with the three controls from exercise 2. The risk of chasing the number for its own sake is the usual one: small changes stop being deployed so as not to put the statistic at risk.

Time to restore. A median of 4 minutes, which is elite, but with one case of 95 minutes. Here the median lies: what hurts is the tail. The change: feature flags on every change of visible behaviour, which turn restoration into seconds with no deployment, and the per-dimension alarm that cuts the detection time, which is where 90 of those 95 minutes were.

First, approval from Slack. It is the one with the most impact — 2 h 40 min out of 3 h 20 — the cheapest — an afternoon's integration — the lowest risk — it removes no control, it just makes it more accessible — and the one that also improves frequency indirectly, because waiting for the approval is what pushes people to batch changes. Starting by removing the approval would be attacking the same metric with far more risk and without having met the conditions the team set for itself.

A change of Luis's has travelled the complete path. It started as a request from Sara about the 31 % of delivery incidents and ended in production three hours later, touching the shop's code, a consumer of cola-mercadofresco-pedidos, the Aurora schema and the PedidoConfirmado contract, without anybody typing a command. The branch lasted two days, the PR was reviewed with the build green, the artefact was built once and that same object travelled through the three environments, Marta approved in forty seconds with the information in front of her, and the quality gate confirmed with real metrics that the shop was still healthy.

What makes this work is not the services, it is the two disciplines this lesson has put into practice. The first is compatibility: the migration in expansion phase with the NULLABLE column, with no NOT NULL, no DEFAULT and no index, which turns an irreversible change into a harmless one; and the versioned event with an optional attribute, with the two contract tests almost nobody writes — the old consumer with the new event and the new consumer with the old event — because during a gradual deployment both situations exist at the same time. The second is order: the reader first, the writer second, declared as runOrder in the pipeline and not as something somebody has to remember. That is where the incident module 7 left open gets closed.

You have the test pyramid with its blocking levels and the one almost nobody has — contract tests, fifteen seconds that are the only thing detecting that a third-party consumer is about to break; the per-environment configuration in Parameter Store and the secrets in Secrets Manager, with the rule that a value set by hand on an instance disappears with the next blue/green and comes back as an undiagnosable failure; and the rollback runbook with its hardest decision, the direction: back if only code changed or there was an expansion, forward if there was a contraction.

And you have the numbers. Deployment frequency from 1.2 to 4.8 per week. Lead time from 6 days to 3 hours. Change failure rate from 23 % to 7 %. Time to restore from 47 minutes to 4. With the three readings that go with them: that frequency goes up because the marginal cost of deploying goes down, that time to restore is the metric that really changes the nature of the risk, and that a 0 % failure rate would be a sign of deploying too little — the goal is not to avoid failing, it is for failing to cost four minutes and not forty-seven. Plus the feature flags with AppConfig, which separate deploying from releasing and carry their own debt if nobody retires them, and the conversion of "we do not deploy on Fridays" into a window justified with data: five times more orders at stake and a third of the team available. A business decision, not an article of faith.

The fourth problem of the course is solved, and for around 28 dollars a month. MercadoFresco has governed code, a build that verifies, a deployment that rolls itself back and a pipeline that chains it all together.

But there is an asymmetry that is hard to justify and that this lesson has laid bare twice. The application code is governed; the infrastructure is not. The VPC was created with create-vpc in a terminal. The queues with create-queue. The EventBridge rules by uploading a JSON. The alarms, the security groups, the ALB target groups, the DynamoDB tables: everything exists because somebody typed a command one day, and nowhere is there a record of why. Nobody can recreate MercadoFresco's environment from scratch. Nobody can guarantee that pre-production has the same configuration as production — in fact it does not, and the difference is discovered during every incident. And the very pipeline that exists so that nobody deploys by hand was created by hand, with a JSON on Luis's laptop. The three environments also share account 111122223333, so the blast radius is not bounded, quotas are shared and the bill is not really split.

In module 9, "Infrastructure as code and account governance", we attack the fifth and last problem of the course. 09-01, "AWS CloudFormation", brings declarative templates, stacks, the change sets that say what is going to happen before it happens, and infrastructure rollback. 09-02, "AWS CDK", lets you define that same infrastructure with real code, with abstractions and tests. 09-03, "Elastic Beanstalk", shows the managed alternative and when it pays off. And 09-04, "AWS Organizations", solves the serious separation of environments with separate accounts, service control policies and consolidated billing. By the end of that module, everything we have built across eight modules will be recreatable from scratch with one command.