This is the last lesson of the course. The previous three gave you the foundation (what to read), the context (where the people are) and the catalogue (which tools exist and when). What is missing is the question none of the three answers and only you can answer: where are you heading?

The lesson has an uncomfortable part and it is worth starting there: an honest inventory of what you can do and what you cannot. Courses usually end by congratulating the student, and that congratulation is the worst possible gift, because it produces people who believe they know more than they do and discover the gap in front of a production system. Here we are going to do the opposite: name the gap precisely, because a named gap is a route and an ignored gap is an incident.

After that: four directions in which to go deeper, a verifiable 90-day plan, certifications assessed without marketing, how to demonstrate competence without certificates, what an interview for these roles looks like, and how to keep up to date without burning out.

1. Where you are now: the honest inventory
2. The four directions
3. A 90-day plan
4. Certifications, with judgement
5. How to demonstrate competence without certificates
6. What an interview for these roles looks like
7. Keeping up to date without burning out
8. What does not change
9. Common Mistakes and Tips
10. Exercises
11. Conclusion

It is not a small amount, and it is worth acknowledging with the same precision with which we will then acknowledge what is missing. After module 7 you know how to:

• Design and write a complete CI pipeline: reproducible build, three layers of tests, static quality with a gate, caches, matrix and sharding.
• Produce an immutable artifact, version it automatically, identify it by digest and promote it between environments without rebuilding it — the discipline that breaks the most pipelines in practice.
• Automate a deployment with explicit gates, authentication without long-lived credentials (OIDC), a subsequent smoke test and idempotency.
• Choose a deployment strategy from six, arguing the trade-off, and perform a rollback in minutes by digest, even automatically on metrics.
• Instrument the system with the four golden signals, define an SLO with an error budget and alert on symptoms rather than on causes.
• Harden the supply chain: secrets, SAST, SCA, image and IaC scanning, SBOM, signing and provenance.
• Measure delivery with the four DORA metrics calculated automatically, and use them to build an argument.
• Choose a tool with judgement rather than by fashion, and — most importantly — verify from the negative side: cause the failure a gate is supposed to stop before declaring it sound.

And one cross-cutting capability you learn without noticing: knowing how to justify a technical decision in writing, with its rejected alternative and its review condition. The PIPELINE.md from 07-06 is that skill turned into an artifact, and it is rarer in the market than it seems.

With the same honesty. None of this would fit into a course, and all of it appears as soon as the context grows.

Real scale. Everything you have built operates a service with modest traffic. You have not touched: pipelines with hundreds of repositories and fleets of runners that have to be sized and isolated, monorepos where selective execution is a dependency graph and not a paths: in the YAML, build times measured in hours, distributed cache systems, or the very real problem of the CI bill becoming a budget line discussed in committee.

Multi-region and distributed data. Deploying to one region is a solved problem. Deploying to five with replicated data introduces entire classes of problem this course has not touched: eventual consistency, replication lag, regional failover, deployments in geographic waves, and the fact that a schema migration like those in 04-06 becomes far harder when there are read replicas on another continent.

Regulatory compliance. Segregation of duties, audit evidence, environments with regulated data, log retention, traceable formal approvals, frameworks such as SOC 2 or ISO 27001, and the uncomfortable fact that compliance sometimes contradicts the practices in this course: there are auditors who require that the approver is not the developer, which collides head-on with continuous deployment. Reconciling that is a trade in itself.

Large organisations. The obstacle to continuous deployment in a 500-person company is almost never technical. It is that there are eight teams with different calendars, a change advisory board that meets on Tuesdays, a security department that does not trust development, and a codebase with twenty years of other people's decisions. Lesson 05-04 touched on this; living it is another matter.

Databases in depth. You know how to do safe migrations. You do not know how to tune an execution plan, diagnose lock contention under real load, size connections or operate a replica. And a disproportionate share of serious production incidents are, at bottom, database incidents.

Being on-call. The difference between knowing about reliability and being responsible for it. Nothing teaches as much as being woken by an alert at 3 in the morning, and nothing can simulate it.

What this means. Not that the course falls short: that you have finished the stretch that can be learned from material and are starting the one that is learned from systems and from years. The good news is that the gap is known and named, which is exactly what you need in order to decide where to go.

There is no single route after this. There are four reasonable directions, and the choice matters less than it seems: all four share the same foundation and you can switch. What does not work is attempting all four at once.

What it is. Building and operating the infrastructure and tooling that other development teams use. Your customer is not the end user: it is your colleagues. The product is the road from commit to production.

What to learn, in order:

1. Kubernetes for real — not just deploying onto it: networking, RBAC, admission controllers, operators, resource sizing, why a pod stays Pending.
2. Advanced IaC — reusable modules, state management at scale, generated environments, infrastructure testing, policy as code (08-03).
3. Runner fleet management — autoscaling, isolation between jobs, cost per minute, ephemeral runners. It is the scale problem 04-04 could only sketch.
4. GitOps and progressive delivery — Argo CD or Flux, Rollouts or Flagger, to deploy dozens of services without touching them one by one.
5. Backstage and golden paths — and, more than the tool, the product mindset: interviewing your internal users, measuring adoption, treating the platform as something that has to be made desirable, not compulsory.

Signs this is your path: you are more interested in the system than in the features; you enjoy it when another team deploys thanks to something you built; repeated work frustrates you and you think about abstracting it; you are comfortable being other people's support.

Signs it is not: you need to see the impact on the end user; it exhausts you that your work is invisible when it works; you cannot tolerate constant interruptions, which in platform work are the job, not a distraction.

The risk of the profile: building a platform nobody asked for. The Backstage warning in 08-03 is the general symptom of this direction.

What it is. Applying engineering to operations: keeping the system available, observable and quick to recover, with reliability treated as a negotiable, measured objective rather than an aspiration.

What to learn, in order:

1. Advanced SLOs — choosing SLIs that represent the real experience, multiple windows, burn rates and alerts based on them. The SRE Workbook from 08-01 is the source.
2. Incident management — incident command, roles, communication during the crisis, post-mortems that produce real changes and not a filed document.
3. Queueing theory and performance — Little's law, saturation, why latency spikes non-linearly as you approach capacity. It is what turns "the system is slow" into a diagnosis.
4. Capacity planning — growth projection, load testing (k6), sizing and cost.
5. Chaos engineering — deliberate injection of failures in production with a prior hypothesis and a bounded blast radius. It is verifying from the negative side taken to infrastructure: the same habit from module 7, at another scale.
6. And the least technical and most important thing: eliminating toil, sustainable on-call, and the discipline of not accepting repetitive work as normal.

Signs this is your path: incidents strike you as interesting rather than merely stressful; you like the detective work of correlating signals; you care about the real user experience more than internal elegance; you enjoy measuring.

Signs it is not: on-call is intolerable to you (legitimate, and worth knowing beforehand); you prefer building to diagnosing; ambiguity under pressure freezes you.

The risk of the profile: becoming the team that says no, or luxury support. An SRE who only puts out fires has failed; the job is to eliminate the class of fire.

What it is. Guaranteeing that what reaches production is what you think it is, comes from where you think it does and does not contain what it should not. It is the fastest-growing direction of recent years, pushed by high-impact public incidents and by growing regulation.

What to learn, in order:

1. SLSA in depth — the levels, what each one requires and what can genuinely be demonstrated. You already started in 07-05.
2. Signing, provenance and verification — Sigstore, attestations, admission policies that reject artifacts not signed by the expected identity. Lesson 08-03 insisted: verify identity, not just the existence of a signature.
3. SBOM and inventory — CycloneDX and SPDX, Dependency-Track, and the ability to answer "where is this library?" in minutes.
4. Threat modelling the pipeline — which is the most formative exercise in this branch: what can somebody do who compromises a third-party action? A dependency maintainer? A developer with write access? The CI provider itself? Modelling the pipeline as an attack surface changes how you design it.
5. Compliance — translating technical controls into evidence an auditor will accept, without destroying delivery speed.

Signs this is your path: you spontaneously think about how something would break; you like rigorous detail; you cope well with work that consists of convincing others to accept friction.

Signs it is not: it drains you to be the one setting limits; you are frustrated by success being invisible (nothing happened) and failure being very visible.

The risk of the profile: becoming the department of no. Security that blocks delivery ends up being routed around, and a control that is routed around protects nothing. Lesson 04-03 said it: security has to go inside the pipeline, not on top of it.

What it is. Staying in product, writing software, and being the person who raises your team's delivery practice from within. There is no flashy title attached — sometimes "senior", sometimes "tech lead" — and it is the least glamorous option and the most in demand.

Why it is the most in demand. The vast majority of companies in the world have neither a platform team nor an SRE nor a supply chain specialist. They have between five and thirty developers and a product. What they need is not a specialist: it is somebody who writes good product code and also knows why the pipeline does what it does, knows how to fix it when it breaks and knows how to argue why it is worth maintaining. That profile is scarce because the people who learn this tend to move to the roles with more attractive names.

What to learn, in order:

1. Design and testing — Feathers, Freeman and Pryce, Fowler (08-01). Your competitive advantage is writing code that can be delivered frequently: decoupled, with seams, covered by tests that genuinely verify.
2. Databases — the most profitable gap in section 1.2. Migrations, indexes, execution plans, contention. It is where the expensive incidents are.
3. Architecture for delivery — backwards compatibility, feature flags as a design practice (03-05), expand and contract (04-06), and when not to split things up (05-03).
4. Communication and influence — the decisive skill in this branch. Convincing Diego with numbers and not with principles. The Phoenix Project for others to read; Accelerate to have the data.
5. Maintaining the team's pipeline — with no platform team, somebody has to do it well. That is you, and you already know how.

Signs this is your path: you like writing product and seeing the impact; you enjoy teaching colleagues; you are motivated by the whole team improving more than by being the expert.

Signs it is not: you need deep specialisation; you are frustrated that your delivery contribution has no formal recognition — and often it does not.

Advice for anyone in doubt: start here. It is the direction with the least risk, the one that best keeps your options open and the one that gives you the product context that makes the other three profiles better. Almost all the good platform engineers and SREs you will meet come from having written product first.

Consolidating what you have learned matters more than starting something new. Twelve weeks, without leaving your job, with verifiable deliverables: if you cannot show it to somebody, it does not count.

Objective: make what module 7 taught solid and applied to something real.

Why week 3 matters more than it looks. Without a baseline, in three months' time you will not be able to demonstrate anything. And defining exactly what you count as a "deployment" and as a "failure" is half the value of the exercise.

Objective: choose one of the four directions and genuinely make progress, not attempt four at once.

Concrete examples of a week 6-7 deliverable by direction: platform → a reusable workflow used by two repositories; SRE → an SLO with a burn rate alert that has genuinely fired at least once; supply chain → signature verification with identity that blocks the deployment of an unsigned image; product → an expand and contract migration deployed with no maintenance window.

Objective: turn what you have learned into visible evidence, which is what makes it professionally useful.

Week 11 is the one most people skip and the one that pays best. Explaining something forces you to understand it, and it produces visibility. A 20-minute internal talk on "how we built the pipeline and what we learned" changes how your organisation sees you more than any certificate.

If you fall behind, do not speed up: cut the scope. A small pipeline finished, measured and documented is worth more than an ambitious one left half done. It is the same rule 08-01 gave for reading.

Three legitimate functions, and none of them is "proving you know":

1. An HR filter. In processes with many candidates and automated screening, a certificate gets you through filters. It is their most real function and the least noble. It matters more the larger and more bureaucratic the organisation, and in consultancies, where they are sometimes a contractual requirement with the client.
2. A structured study route. The official syllabus is a reasonable index of what you need to know, and the exam date is a commitment that fights procrastination. This benefit is real even if you never sit the exam.
3. A signal in specific markets. In some countries, sectors and for work with public administration, they genuinely carry weight.

What they are not: proof of competence. Everybody in the sector knows there are certified people who cannot operate anything, and people without a single certificate who keep critical systems running. A competent interviewer does not hire you for the certificate; at most, it gets you a conversation.

• An exam consisting purely of multiple choice about memorising service names. It measures short-term memorisation. The hands-on ones (CKA, CKS) are worth far more because you cannot pass them without knowing how to do things.
• It certifies a tool only used by the people selling it. Its value is tied to the commercial health of one product.
• Nobody asks for it in the job ads in your market. A ten-minute check: search 30 ads for the role you want and count how many mention it. If it is zero, you have your answer.
• It expires in a year and renewing costs as much as taking it. A subscription disguised as a credential.
• It comes from a course platform rather than from whoever builds the technology. The "certificates of completion" from online courses are not certifications and on a CV they take up space without adding signal. (Including this course's: what counts is the repository you have built, not the diploma.)
• You take it to avoid the hard part. If you study for a certification because studying is more comfortable than putting your pipeline into production and living with it, you are substituting the appearance of learning for learning. It is the most common failure and the most expensive.

A practical decision rule: a certification is worth it if (a) its syllabus matches what you were going to study anyway, (b) the exam is hands-on or at least applied, and (c) it appears in the ads in your real market. If it meets all three, go ahead. If it only meets (a), study the syllabus and do not pay for the exam.

What a good interviewer wants to see is evidence of decisions, not of knowledge. And there you have an advantage, because module 7 left you exactly that.

1. The final project repository. Public, with a README explaining what it is and how to run it. A complete, working pipeline, with a real commit history. It is worth more than any list of technologies, because it is verifiable in five minutes.

2. The PIPELINE.md. It is your best asset and the rarest. A document that says, decision by decision: what was chosen, what was rejected, why, and which condition would force a review. Almost nobody has anything like it, and it demonstrates the skill that separates a senior from a junior: reasoning about trade-offs under constraints. If in an interview you can show only one thing, show this.

3. The POSTMORTEM.md. It demonstrates that your system failed and held up. Anyone can show a green pipeline; showing one that went red for the right reason and recovered in minutes is another category. And it demonstrates the habit of verifying from the negative side.

4. The numbers. "We went from 1.5 deployments a week to 12, and from 68 hours of lead time to 3.5" is a sentence that changes an interview. Not because the numbers are spectacular, but because it shows that you measure, which is what almost nobody does.

5. Public contributions. Even small ones (08-02). An accepted documentation PR in a well-known project shows you can work with somebody else's process: reading a CONTRIBUTING.md, accepting review, iterating.

6. Talks and articles. An internal talk counts. A technical article in Spanish, where there is far less quality content, has disproportionate reach.

7. How you talk about your failures. The most reliable indicator of all. Somebody who can say precisely what went wrong, why, what they learned and what changed afterwards has genuinely operated systems. Somebody with only successes has either operated nothing or is not being honest.

They are rarely about algorithms. They usually have three parts: a technical conversation about experience, the design of a system or a pipeline, and sometimes a hands-on or debugging exercise. What is being assessed is not whether you know the answer, but how you reason when information is missing.

Eight real questions and what the interviewer is looking for:

1. "Talk me through how a change goes from somebody writing it to being in production, in your last project."

Looking for: whether you know the whole flow or just your part, and whether you spontaneously mention the gates and their reasons. A good answer mentions what happens when something fails at each stage. It is the whole of 04-01.

2. "Why should you not rebuild the image when promoting from staging to production?"

Looking for: whether you understand artifact immutability or are repeating a rule. The complete answer includes that a rebuild may resolve different dependencies, that the digest is no longer the verified one and that you lose traceability between what was tested and what was deployed. It is 02-06.

3. "You have 200 deployments a month and a 15% change failure rate. Where do you start?"

Looking for: whether you start by diagnosing or by proposing solutions. The good answer starts by asking: what kind of failure? At which stage is it detected? How long does reverting take? If rollback is fast, 15% hurts less than if it is slow. Whoever answers "I'd add more tests" without asking anything, fails.

4. "How would you deploy a change that breaks database schema compatibility, with no maintenance window?"

Looking for: expand and contract (04-06). And above all, whether you mention that the deployment goes in several phases and over several days, that the new code must tolerate the old schema, and what you do about the backfill and about locks on a large table. It is the question that most separates levels.

5. "What is the difference between continuous delivery and continuous deployment, and which would you recommend here?"

Looking for: conceptual precision (03-01) and, above all, that you do not give an automatic answer. The good one starts with "it depends on what is on the other side": a product with enterprise clients and contractual windows is not an internal SaaS. Answering "continuous deployment, always" is the 08-02 warning sign applied to you.

6. "Your pipeline takes 40 minutes and the team is complaining. What do you do?"

Looking for: method before solutions. First measure where the time goes, then separate the critical path from everything else, and only then caches, parallelisation, sharding or selective execution (04-04). The most frequent incomplete answer is proposing optimisations without measuring. The excellent one adds: "and I'd check we're not removing checks to go faster" — the false green.

7. "How do you manage secrets in the pipeline?"

Looking for: whether you mention not having secrets (OIDC, roles) before talking about where to store them. Then: least privilege, rotation, masking in logs and what you do if one leaks — rotate first, delete afterwards (04-03, 08-02). Mentioning OIDC without being asked is a very positive signal.

8. "Tell me about a production incident you were responsible for."

Looking for: honesty, a causal chain rather than a single culprit, and what changed afterwards. The best answer includes what was tried and did not work, and ends with a concrete, verifiable improvement. Whoever says "I've never had an incident" loses the question: either they have operated nothing, or they did not notice.

The cross-cutting part. In all of them, the interviewer is assessing the same thing: whether you distinguish what you know from what you assume, whether you ask about the context before answering, and whether you mention trade-offs without being asked. They are exactly the markers of good advice from 08-02. Now you are the one applying them.

The hype cycle. Every new technology travels the same arc: appearance, disproportionate enthusiasm, disillusionment when the rough edges are discovered, and — if it survives — steady productivity with decent documentation. Most of the content you will see corresponds to the enthusiasm phase, written by people with three weeks of the tool and none of it in production.

The practical consequence: arriving late to a good tool costs very little. You will learn it when it has better documentation, more examples and fewer rough edges. Arriving early to a bad one costs a migration, and migrations are paid for over years.

What to follow:

• The documentation and release notes of what you use in production. Non-negotiable.
• The security advisories of your direct dependencies.
• One weekly source of depth (the 08-01 plan).
• One community space where you genuinely take part (08-02).

What to ignore:

• Announcements of tools that solve problems you do not have.
• Comparisons written by somebody selling one of the options.
• Content promising that "X is dead". X is not dead; there are banks running COBOL.
• Anything that produces anxiety without producing a concrete action.

The discard rule: if you have been seeing a name for six months and it has never solved a problem of yours, delete it from your radar. If it genuinely matters, it will come back.

And the central idea: fundamentals last and tools do not. What you have learned in this course about small batches, fast feedback, immutable artifacts, backwards compatibility, error budgets and verifying from the negative side will still be true when GitHub Actions is called something else. Jenkins, Travis, CircleCI, GitLab, Actions: five tools for the same six practices from 02-01. Whoever learned the practices changed tool in two weeks. Whoever learned only the tool started from zero every time.

Invest in fundamentals at a ratio of ten to one against tools. And when you are unsure whether something is a fundamental or a fashion, apply the time filter: was this true ten years ago and will it be true in ten years' time?

The course's invariant principles, in a list you can reread five years from now with any tool:

1. Integrate early and in small batches. Batch size is the variable with the greatest influence on risk. Everything else is a consequence.
2. If the pipeline is red, fixing it is the priority. A broken pipeline that is tolerated stops being a pipeline and becomes decoration.
3. Build the artifact once and promote that same artifact. If you rebuild, you have not tested what you are deploying.
4. Automate the repetitive; leave judgement to people. Automatic gates for what is verifiable, approvals for what requires context.
5. Fast feedback is worth more than exhaustive feedback. A 2-minute test that catches 80% beats a 2-hour one that catches 95%.
6. Being able to revert matters more than not making mistakes. The goal is not the perfect deployment: it is for failure to be cheap.
7. Measure what you want to improve, and measure your own trend, not a survey's.
8. Reliability is a negotiable objective. 100% is the wrong number; the error budget turns an argument about opinions into a decision.
9. Security goes inside the pipeline, not on top of it. A control that gets in the way is routed around, and a control that is routed around protects nothing.
10. Document the why, not the how. The code says what it does; only you can say what you rejected and under what condition it gets reviewed.
11. Failures belong to the system, not to people. A post-mortem with a culprit guarantees that the next incident gets hidden.
12. Verify from the negative side. Anyone can check that a gate lets the good through; checking that it stops the bad requires manufacturing the bad.

None of these twelve mentions a tool. None of them will expire before your career does.

• Choosing a direction by salary or by the prestige of the title. All four pay well and the difference between them is smaller than the difference between doing it well and doing it badly. Choose by the signs in section 2, which describe what will be sustainable for you over years.
• Attempting all four at once. It produces superficial knowledge in all of them. Choose one for 6-12 months; the others will still be there and the foundation is shared.
• Collecting certifications as a substitute for experience. It is detected in an interview within two questions. It is the comfortable way of avoiding the hard part, which is putting something into production and living with it.
• Skipping the baseline. Without measuring the starting point you will not be able to demonstrate improvement, and demonstrating improvement is what gives you room to keep investing.
• Waiting to "be ready" before giving a talk or writing. Nobody feels ready. The right level is that of somebody who solved the problem three months ago: you remember where the difficulties were, which the expert has already forgotten.
• Not asking for the responsibility. If you want to operate systems, ask to join the on-call rotation. If you want platform work, offer to maintain the team's pipeline. Experience is rarely offered unprompted; it is asked for.
• Tip: write the plan and put dates on it. A plan with no date is a wish. Review it every three months and allow yourself to change it with the reason written down.
• Tip: teach what you have just learned. It is the cheapest multiplier: it fixes the knowledge, exposes the gaps and makes you visible.
• Tip: keep your own record of professional decisions, in the same format as PIPELINE.md: what you chose, what you rejected, which condition would make you change. It works just as well for a career as for a pipeline.

Write your own direction decision, in one page, with this structure:

1. What I found most interesting in the course, with specific lessons (not "module 3", but "the part of 03-06 about why you alert on symptoms").
2. What I found tedious or hard, with the same specificity.
3. The chosen direction and the three signs from section 2 that I recognise in myself.
4. The warning sign: what worries me about that direction and how I would check it before committing a year.
5. The concrete first step, this week.

If you work better with somebody else's case, do it for Nuria (frontend/QA at Reservalia, who handled the E2E tests and the Grafana dashboard from 07-04, enjoyed measuring, is drained by infrastructure tasks).

A colleague with two years' experience, who is finishing this course, writes to you:

"I've decided to take CKA, Terraform Associate and AWS DevOps Professional this year. With all three I'm bound to land something better. I'll start with AWS since it's the most highly valued, right?"

Write your reply. It must include: what is right about their approach, what is wrong, what you propose concretely (with an order and a reason), and what would do more for their career than the three certifications put together. Justify it with the criteria from section 4, not with an opinion.

Choose three of the eight questions in section 6 and write your real answer, as if you were in the interview, based on what you built in module 7. Then, for each one, note what your answer is missing and what you would have had to experience in order to give it in full. That second part is the real exercise: it is your learning plan in the form of concrete gaps.

Solution 1

There is no correct answer; there are honest answers and self-flattering ones. An example, for Nuria:

1. The most interesting part. Lesson 03-06, specifically the idea of alerting on symptoms rather than causes: it was the moment she understood why her team had 40 alerts nobody looked at. And 07-04, building the dashboard and watching the SLO being consumed in real time: the first time a metric told her a story.

2. The tedious part. Lesson 03-03, Terraform. She understood the concept, ran the steps, and did not enjoy a single minute. Also the infrastructure sizing in 04-04: it felt alien to her.

3. Direction: SRE / reliability. Three signs from section 2 that she recognises: incidents strike her as interesting rather than merely stressful (in the 07-04 lab, breaking the endpoint and chasing the effect through the metrics was what she most enjoyed); she cares about the real user experience, which is where her QA profile comes from; she enjoys measuring.

4. The warning sign: on-call. She has never been on-call and does not know how she copes with being woken up. It is the factor most people underestimate when choosing this direction, and the hardest to reverse once committed. How she checks it before committing a year: she asks to join the on-call rotation as a second person for two months — shadowing, without being responsible. It is the cheapest and most direct test possible, and the information it gives cannot be obtained by reading.

5. First step this week. Review the SLO she defined in 07-04 and ask whether the SLI genuinely measures the user experience or only whether the server responds. And start the SLO chapter of the SRE Workbook (08-01) with that question written down.

What makes this a good answer: that point 2 is honest. Whoever writes "I found it all interesting" has not done the exercise. And that point 4 has a cheap and reversible check rather than an irreversible decision.

Solution 2

What is right. They have initiative, they have chosen three legitimate certifications in real technologies rather than in marginal products, and they have set a deadline. That already sets them apart from most people.

What is wrong, and it is four things:

1. The order is inverted. Starting with AWS DevOps Professional with two years' experience is the worst decision in the plan. The professional exams assume broad operational experience; without it, the only way to pass is mass memorisation, which is forgotten in months and leaves no capability behind. The sensible order is Terraform Associate (3-6 weeks, cross-cutting, accessible, and it gives them IaC that serves all four directions), then CKA if they are genuinely going to touch Kubernetes, and AWS Professional later or never, depending on their actual work.
2. "With all three I'm bound to land something better" is an untested hypothesis, and testing it takes ten minutes: let them search 30 ads for the role they want in their market and count how many ask for each one. They will probably discover that Terraform and Kubernetes appear a lot, and AWS Professional considerably less than they think.
3. "The most highly valued" is a statement with no context, the 08-02 warning sign. Valued by whom? In AWS partner consultancies, a great deal; in product companies, considerably less than showing a system that works.
4. And the underlying problem: three certifications in a year is between six and nine months of study. That is nearly all of their learning time for the year devoted to syllabuses rather than to systems. With two years' experience, what they lack is not syllabus: it is having operated things.

What I propose. One certification this year: Terraform Associate, because its syllabus matches what they should study anyway, it is affordable in time and it is cross-cutting across the four directions. And then decide on CKA with a piece of data in hand: if in six months they have touched Kubernetes at work, go ahead; if not, it is a certificate about something they do not use and they will forget it.

What would do more for their career than the three put together. The 90-day plan from section 3: apply the pipeline to a real project, measure the DORA baseline, write the PIPELINE.md, break something on purpose, document the post-mortem, measure again and tell the story in an internal talk. That is twelve weeks, not nine months, and it produces something they can show. In an interview, "here is the repository, this is the decisions document and these are the before and after numbers" opens a conversation a certificate does not open. The certificate, at most, gets them the interview; the other thing wins it.

And an honest nuance: if they work or want to work in a consultancy where certifications are a contractual requirement with clients, the calculation changes and AWS Professional may make sense earlier. Let them check that first, because it is the only case in which their original plan would be defensible.

Solution 3

An example with two of the eight questions.

Question 4 — a migration that breaks compatibility, with no maintenance window.

Answer based on module 7: "In three phases separated in time, with the expand and contract pattern. Expansion phase: I add the new column allowing nulls, without touching the old one, and deploy code that writes to both and reads from the old one. Data migration: a backfill in batches, with pauses, so as not to lock the table or saturate the database. Contraction phase, days later and in a separate deployment: the code switches to reading from the new one, and only when it has been stable for a while do I drop the old column. The key is that at no point is there a version of the code incompatible with the current schema, because during the rolling deployment versions coexist."

What it is missing. I have not done this on a table with millions of rows and real traffic. I do not know how long a backfill like that takes, nor how the lock of an ALTER TABLE behaves under load in PostgreSQL, nor how you coordinate it if there are lagging read replicas. Nor have I had to revert halfway through a migration, which is the hard case.

What I would have to experience. A real migration on a large table in production, with metrics in front of me. And testing it beforehand on a copy of the data at realistic volume, which is what 04-06 recommended and which in the lab I never did at real volume.

Question 8 — an incident you were responsible for.

Answer based on module 7: "In the 07-04 lab I caused a failure on purpose: I introduced a latency regression in the availability endpoint and watched the SLO start consuming error budget. The symptom-based alert fired within a few minutes — not on CPU, but because the p95 latency went outside the target — I ran rollback.yml by digest and the service recovered in a few minutes. I documented it with the blameless post-mortem template, and the conclusion was that the alert worked but arrived late for the error budget we had defined."

What it is missing — and this has to be said in the interview, not hidden. That it was a failure I caused myself, in a controlled environment, with no real users affected, nobody asking why it was not working and none of the pressure of deciding with incomplete information at 3 in the morning. It is a rehearsal, not an incident.

What I would have to experience. Being in the on-call rotation for a system with users. The difference is not technical: it is that in a real incident you do not know what has changed, there are several hypotheses at once, somebody is asking you how long is left, and the decision to revert is taken on incomplete data.

Why answering this way works in an interview. A competent interviewer values "I did it in a controlled environment and this is what my experience is missing" far more than an inflated answer. Distinguishing what you know from what you assume is exactly the marker section 6 identified as cross-cutting, and saying it yourself before they detect it works in your favour.

In 01-04 you met Marta, Diego and Nuria, and a team that deployed 1.5 times a week, took 68 hours from a change being written to it reaching production, broke production on 6.5% of deployments and took 68 minutes to recover when that happened. Nobody deployed on Fridays. Nobody remembered which version had been there before. And deploying was, for everyone, an event you prepared for in advance and lived through with the tension of somebody expecting something to go wrong.

Four modules later, that same team deployed 12 times a week, with 3.5 hours of lead time, a 3.8% failure rate and 9 minutes to recover. The same three people, the same product, the same cloud. What changed was not the people or the technology: it was how the road to production was organised.

And Marta had said it at the start, when it still sounded like a provocation: "I'd rather deploy ten times a day and have every deployment be boring".

Now you know it was not a clever line. It was a complete technical thesis, and the whole course has been its demonstration. A boring deployment is a small deployment — because the batch is small, there is little that can go wrong. It is a verified deployment — because the gates have already checked what can be checked, and somebody made sure they stop the bad by causing it. It is a reversible deployment — because the artifact is immutable, identified by its content, and going back is an operation of minutes, not a rebuild. And it is an observed deployment — because if something degrades, an alert on a symptom that matters to a user will say so, not a human watching graphs just in case.

Making boring what used to be frightening is not making it unimportant. It is the opposite: it is having applied so much engineering that it no longer requires heroism. Fear of deployment was never irrational — deploying by hand, with no tests, with no way back and with no idea whether it worked should be frightening. What you have learned is how to eliminate the conditions that justified it.

There is one last thing, and it is the one that hands responsibility back to where it belongs.

The pipeline is not the goal. It is easy to forget that after seven modules building it. Nobody has ever paid for a pipeline. Reservalia's users do not know it exists and would not care if they did: what they care about is being able to book an appointment, the system not going down on a Saturday morning and their data being safe. Everything you have built — the three layers of tests, the digest, the signature, the SLO, the four-minute rollback — exists for one thing only: delivering value safely and without heroics.

When in time you face the decision of whether to add another gate, another tool or another stage, the question will not be "is this a best practice?". It will be the one from section 12 of 08-03: what measured problem does it solve, and for whom? If the answer is "for nobody, but it looks better", you know what to do.

You have the foundation to read with judgement, the community to ask when the problem is one of context, the catalogue to recognise what exists and what it will cost you, and a direction for the coming months. You also have, and this matters more, a repository with a system that works, a document explaining why it is the way it is, and the proof that it failed and held up.

What you do with all of that no longer depends on the course.

May your deployments be boring.