Lesson 08-01 ended by pointing at a gap: there is a class of knowledge that is in no book because it depends on context and expires too quickly to be published. Why your workflow_run does not fire even though the YAML is identical to the example. Why OIDC against AWS works in one repository and not in the one next door. Why that third-party action stopped working on Tuesday without changing version. None of those answers is in Continuous Delivery, and many are not in the official documentation either: they live in the head of somebody who ran into the same thing three weeks ago.

This lesson is about where those people are, what to expect from each place, how to ask so that you get an answer and — the thing almost nobody does and the thing that teaches fastest — how to give something back from day one. It is also about something less pleasant: most of the content circulating in these spaces is noise, fashion or cargo cult, and you need a filter.

1. Why this genuinely matters
2. The map of spaces: what to expect from each
3. Foundations and ecosystems
4. Events: conferences, meetups and the hallway
5. Spanish-language communities and why to take part in two languages
6. How to ask so that you get an answer
7. How to contribute from day one
8. Information hygiene: telling advice from cargo cult
9. The ethics of sharing logs and data
10. Common Mistakes and Tips
11. Exercises
12. Conclusion

There are three types of problem and only the third justifies this lesson.

Knowledge problems. "What is a digest?" They are solved by reading. Books and documentation are enough.

Skill problems. "I do not know how to write a reusable workflow." They are solved by practising. Module 7 was exactly that.

Context problems. "The reusable workflow works in my repository but when I call it from the organisation's repository, secrets: inherit propagates nothing and the error does not say why." This one is not solved by reading or by practising, because the information you need is the intersection of a specific tool, a specific version, a specific configuration and an undocumented behaviour. It is solved by asking somebody who has already been there, or by finding the thread where somebody else asked.

When you were working through a module 7 lab, the context problems were anticipated: the material warned you about the failures. In your real work they will not be. And the gap between the person who stays blocked for three days and the person who solves it in two hours is almost never a difference in talent: it is a difference in knowing where and how to ask.

There is a second reason, slower and more important. Communities are where you see the distribution of solutions. You have seen one way of building a pipeline: this course's way, with its decisions and its biases. In a community you see fifty different contexts with fifty different trade-offs, and that is what turns a learned technique into judgement of your own. You cannot calibrate whether your decision is reasonable if you only know one decision.

GitHub Community (GitHub's discussions forum) is the first place to go with a GitHub Actions problem that is not an obvious bug. It has the advantage that people from the platform itself answer and that the answers get indexed. The Actions category concentrates exactly the problems from module 6: GITHUB_TOKEN permissions, contexts available in each event, concurrency limits, the behaviour of workflow_run and of environments with reviewers.

The GitLab forum works similarly and with the same Discourse structure. For GitLab there is also a valuable peculiarity: GitLab's issue tracker is open and it is the product itself. Many "why is this like this?" questions have a literal answer in the issue where it was discussed.

Jenkins has the oldest ecosystem and the most scattered one: mailing lists (jenkinsci-users), its own Jira for core and plugin bugs, and chat channels. If you work with Jenkins — which, as 06-01 said, is still the case in half of the companies with any history — learning to search its Jira is a concrete and profitable skill: most of a plugin's odd behaviours are reported there, sometimes years ago, with a workaround in comment 14.

The Kubernetes Discourse and the CNCF forums cover the orchestration part of 06-05. Kubernetes also has a documented governance model with SIGs (special interest groups) and its own recorded public meetings: if one day you need to know why an API behaves the way it does, the answer is in a SIG's notes.

What to expect: precision about the tool. What not to expect: advice on whether you should be using that tool at all. In the Jenkins forum, the answer to "should I migrate to GitHub Actions?" will have a predictable bias, exactly as the opposite question will in the other place.

Stack Overflow is still the best archive of specific errors in existence. If you have a literal, unusual error message, putting it in quotes in a search engine and finding the 2019 question with the accepted answer still works and still saves hours.

But we should be honest about its state. The volume of new questions has fallen steadily, for three reasons that compound: AI assistants now answer most mid-level questions with no social cost; the site's culture became notoriously hostile to anyone who asked badly, which drove beginners away; and a good deal of support for modern tools has moved to Discord and to each product's own forums.

Practical consequence: treat it as an archive, not a community. Always search it, and check the date and the version of every answer before applying it. Half the top-voted Docker or Actions answers describe obsolete syntax or practices now discouraged — there are heavily upvoted answers recommending passing secrets as build arguments, something 04-03 taught you never to do because they end up in the image layers. Votes measure age as much as quality.

Kubernetes Slack is the canonical example: tens of thousands of people, channels by SIG and by topic, and project maintainers answering. CNCF has equivalent spaces for its projects, and many of the tools in this module (Argo, Flux, OpenTelemetry, Backstage) have their channel there or a Discord of their own.

The good part: speed. A well-framed context problem in the right channel can be solved in twenty minutes by the person who wrote the code in question. Nothing compares.

The bad part, and it is serious: the conversation does not persist in any useful way. What gets solved in Slack is lost, is not indexed and helps nobody else. It is a systematic waste of knowledge: the same problems get solved over and over without leaving a trace. The countermeasure is in your hands: when a channel solves something undocumented for you, write it down. In your PIPELINE.md, in your team's wiki or — better — as an answer in the official forum or as a PR to the project's documentation. Turning an ephemeral conversation into a searchable artifact is one of the most valuable and least performed contributions there is.

And one rule of coexistence: in these spaces people answer out of goodwill, in somebody's free time. Asking well is not politeness, it is what keeps the system working.

r/devops is useful for something no other space gives you: knowing what is genuinely frustrating the trade. Threads about specific tools, failed migrations, salaries and burnout give you a picture of the profession that appears at no conference, where everybody presents successes.

Its bias is obvious and must always be discounted: people post when something goes wrong. Nobody writes "we've had Jenkins for three years and it works". The result is a systematically negative impression of every mature tool and a systematically enthusiastic one about the new ones — until they stop being new and the complaint threads start appearing. It is a thermometer with a miscalibrated scale: it measures relative trends well and absolute values badly.

There is a second bias: the people who post on r/devops are not representative of the sector. The pure-infrastructure profile, medium or large companies and English-speaking environments are all over-represented. If you read there that "nobody uses X any more", it means nobody in that subset uses it.

They are useful for discovering that something exists and, occasionally, for reading the comments of the person who built the system the article is about, which are often worth far more than the article. Threads about public post-mortems and about real architectures tend to have a high technical density.

Their biases: a strong leaning towards the novel and the contrarian, over-representation of startups and of extreme-scale contexts, and a tendency towards very self-assured commentary on domains the commenter does not know. A piece of HN advice about distributed databases might come from somebody who operates them or from somebody who read an article yesterday, and the tone is identical.

Lobsters is smaller and has less noise, but the same profile.

Recommended use: a quick scan, two or three times a week at most, for your radar. Never as a source of decisions. The attention cost of these sites is their real danger: they are addictive and produce the sensation of learning while you are only keeping up.

There is real value there — contacts, job offers, occasional content from people who do operate systems — wrapped in a very thick layer of personal marketing. The format rewards the categorical statement, the "5 things" list and the story with a moral; it penalises nuance, which is exactly what you need.

Sensible use: professional network and visibility for your work (08-04 will talk about this), not a source of learning. And be especially wary of the "DevOps roadmap" diagrams with forty logos: they cement the worst possible idea, which is that all of this consists of accumulating tools.

Here is the most reliable knowledge of all, and the worst indexed.

When you want to know why a tool behaves the way it does, the definitive answer is in the issue or the RFC where it was decided. There you will see the alternatives considered, who objected and with what argument, and which trade-off was accepted. It is extraordinarily formative reading: it teaches you how the people who design what you use think about trade-offs.

The problem is finding it. GitHub's issue search is mediocre, RFCs are scattered and mailing lists have awkward archives. A technique that works: search a general search engine with site:github.com/<org>/<repo>/issues plus the error message or the exact name of the option. And sort by comments rather than by relevance: long issues are where the workaround lives.

One concrete and very profitable habit: when a tool surprises you — it does something you did not expect and the documentation does not explain it — look for the issue before assuming the bug is yours. Half the time it is a known, discussed behaviour with a solution in a comment.

Three names come up constantly and it is worth knowing what they mean.

CNCF (Cloud Native Computing Foundation). It hosts Kubernetes, Prometheus, OpenTelemetry, Argo, Flux, Helm and a good part of the ecosystem 06-05 and 08-03 touch. It classifies its projects into three levels: sandbox (experimental), incubating (real production use, growing community) and graduated (mature, established governance, several companies depending on it).

What it means for your decisions. A project being graduated is a reasonable signal that it is not going to disappear and that it does not depend on a single company — the risk of "abandoned project" or "licence change" drops considerably. Being sandbox means the opposite: interesting, possibly excellent, but adopting it in production is a bet. That distinction is a direct criterion for the "who maintains this?" question that 08-03 proposes before putting any tool into your pipeline.

What it does not mean. It is not a stamp of technical quality nor of you needing it. The CNCF catalogue — the famous map with hundreds of logos — is often used as a shopping list, and that is exactly the wrong use: it is a catalogue of parts for problems most teams do not have.

OpenSSF (Open Source Security Foundation). This is where much of the supply chain security work you applied in 04-03 and 07-05 lives: Sigstore, the SLSA framework, project scorecards, good-practice guides. If that part of the course interested you, it is the ecosystem to follow.

Linux Foundation. The umbrella over the two above and over many other projects. Also the issuer of a family of certifications that 08-04 will assess in detail.

KubeCon + CloudNativeCon is the big event of the CNCF ecosystem: thousands of attendees, dozens of parallel tracks, and a considerable commercial weight — some of the talks are, with more or less disguise, product presentations. The talks are recorded and published, which has an important consequence for your decision: if you are going for the talks, you do not need to go.

DevOpsDays is a different format and, for most people, a more useful one: local events, one or two days, organised by communities in many cities, with accessible prices and a format that includes open spaces — sessions with no speaker where the attendees propose the topics and discuss them as a group. That is where people really share what does not get told in a talk: the failures, the real costs, the migrations that went badly.

FOSDEM, in Brussels, is free, enormous and focused on free software, with rooms dedicated to individual projects. It is the event with the best knowledge-to-price ratio there is, and also the most chaotic.

Local meetups. Groups of a few dozen people, monthly, in your city. Their value is not in the average technical level of the talks — variable — but in the fact that they are the real professional network of your job market. The people who make hiring decisions at companies in your city are there.

Why the hallway is worth more than the talks. The talks are recorded, polished and present the version that turned out well. The hallway conversation is where somebody tells you "we tried that and dropped it after six months, let me tell you why". That is content that exists in no other format, because nobody goes on stage to say that nobody uses their internal platform.

A practical rule for making the most of an event: pick three talks you genuinely want to see, ignore the rest (you will watch the recordings if at all), and spend the remaining time talking to people. Prepare a specific question about your own system and ask it twenty times to twenty different people. You will come back with twenty contradictory answers, which is exactly the material you need to develop judgement.

There is an active Spanish-speaking ecosystem: local Kubernetes and Docker groups in the main cities of Spain and Latin America, AWS and other cloud communities with regional chapters, DevOpsDays in several Spanish-speaking cities, Telegram and Discord channels by technology, and a growing output of technical content in Spanish.

Why it is worth taking part in both languages rather than choosing one:

• English has the volume and the source. The documentation, the issues, the RFCs and most of the expert answers are there. Giving up English means giving up the long half of the knowledge, and the barrier is much lower than it looks: written technical English is a small and highly repetitive subset of the language. You learn it by reading issues.
• Spanish has your market's context. What companies in your country are like, what they pay, what your regulations require, what hiring processes look like. None of that is on r/devops.
• And there is an asymmetry in your favour: there is far less quality content in Spanish. Writing in Spanish about what you already know — what you built in module 7, for example — has a much higher chance of being read and of standing out than doing it in English, where you compete with thousands of people. It is the fastest route to the professional visibility 08-04 will mention.

This section is the most practical in the lesson. The difference between an ignored question and one answered in ten minutes is almost never the difficulty of the problem: it is how much work you save the person answering.

Let us take a real failure from the course. In 07-03 you deployed by digest and several labs tripped over the same thing: cd.yml fires with workflow_run, CI went green, but the deployment either never runs or fails to authenticate against AWS.

Subject: My deploy doesn't work

Hi, I have a GitHub Actions workflow to deploy to AWS and it doesn't work. CI passes fine but the deploy doesn't. I've tried everything and I don't know what to do. Has anyone had this problem? Thanks.

Why nobody is going to answer:

• There is no error. "It doesn't work" describes an emotion, not a behaviour. Does it not fire? Does it fire and fail? Does it fail at which step?
• There is no code. Nobody can reason about YAML they cannot see.
• There are no versions or environment. Hosted or self-hosted runner? Which version of the actions? Public or private repository? Is there an environment with reviewers in the way?
• "I've tried everything" contributes nothing and is also untrue, and the person answering knows it. What it achieves is that the first reasonable suggestion — which you have probably not tried — looks like a waste of time for both of you.
• The subject line is unsearchable. A year from now, nobody with your same problem will find this thread.

Subject: workflow_run does not trigger the deployment workflow when CI runs from a fork PR

Context. I have two workflows in a private repository: ci.yml (runs on push and pull_request) and cd.yml, which should run when CI finishes successfully on main. The goal is to deploy to ECS the same image digest that CI published, without rebuilding.

Expected behaviour. On merging to main, ci.yml finishes green and cd.yml starts.

Actual behaviour. ci.yml finishes green (run #482), but cd.yml does not appear in the Actions tab. There is no failed run: there is no run at all.

Environment.

• Private repository, organisation on the Team plan.
• GitHub-hosted runners, ubuntu-latest.
• actions/checkout@v4, aws-actions/configure-aws-credentials@v4 (both pinned by SHA).
• Both workflows are on main.

The cd.yml trigger:

on:
  workflow_run:
    workflows: ["CI"]
    types: [completed]
    branches: [main]

jobs:
  deploy:
    if: ${{ github.event.workflow_run.conclusion == 'success' }}
    runs-on: ubuntu-latest
    environment: production

What I have already checked:

1. The CI workflow's name: is exactly CI (verified in the file, not in the interface).
2. The ci.yml run that went green executed on main — the run's interface confirms it.
3. The production environment exists and has a reviewer assigned; with a manual workflow_dispatch, cd.yml does run and waits for approval correctly. So the problem seems to be in the trigger, not in the deployment.
4. I looked at whether the failure was a token permissions issue, but there is no run at all, so I have ruled that avenue out.

Current hypothesis. That branches: [main] in workflow_run filters on the branch of the CI run rather than on the merge's target branch, and that in my case they do not match. I have not found confirmation of this in the documentation.

The specific question: which branch exactly is the branches filter evaluated against in a workflow_run trigger? And is there any way to check why a workflow_run did not fire, given that no record is left behind?

Why this one gets answered:

The most useful side effect: writing the good question solves the problem without ever posting it in a very high percentage of cases. The act of having to state what you expected, what happened and what you ruled out is a debugging method. When somebody tells you "write the problem up as if you were going to post it", they are not fobbing you off: they are giving you the technique.

• One problem per question. Questions with three chained problems do not get answered.
• Paste text, not screenshots, unless the problem is visual. Text is searchable, quotable and readable on a phone.
• Trim the log to what is relevant, but include the surrounding lines. An error usually has its cause five lines earlier.
• Post in one place at a time. Asking simultaneously on Slack, the forum and Stack Overflow wastes three people's time.
• Come back and close the thread. If you solve it — you or somebody else — write down the solution. An abandoned thread with "fixed it, thanks" is a cruelty to whoever arrives in future with your same problem.

The widespread belief is that you have to be an expert to contribute to an open source project. It is false, and believing it costs you the fastest learning route there is.

Why contributing teaches so fast: it forces you to understand a real system you did not write, with quality standards you cannot negotiate, and you receive review from people who know more than you, for free. There is no other way to get that.

Five ways to contribute without being an expert, ordered by ease:

1. Reproducing issues. A maintainer receives "this doesn't work" with no versions and no example. Somebody who picks up that issue, reproduces it in a minimal repository, confirms which versions it happens in and writes that up in a comment has done half the work of fixing it. It is what maintainers are most grateful for and almost nobody does it. And for you it is a debugging exercise with a known solution at the end.

2. Documentation. You have just worked through a whole course tripping over badly explained things. That newcomer's perspective is an asset that disappears within weeks: somebody who has been on a project for two years no longer sees what is missing. Fixing an example that does not work, adding the step that was missing, clarifying an ambiguous sentence: all of those are small, welcome PRs.

3. Examples. Many projects have an examples/ directory with the basics. A real integration example — how to use that tool inside a GitHub Actions workflow, to name something you now know how to do — is a high-value, low-risk contribution.

4. Translations. If the project has translated documentation, there is almost always a gap in Spanish. It is a contribution that does not require understanding the code in depth and that serves a lot of people.

5. Reviewing other people's PRs. You do not need permission to read an open PR and comment. Trying it out and saying "I applied it in my environment and it works / it fails with this" is a useful review, and reading a project's PRs is the best way to learn how things are written there.

Where to start: the project you already use and have already tripped over. The motivation of fixing something that annoyed you personally is the only one that survives the first rejected PR. Look for the good first issue or help wanted labels, read the whole CONTRIBUTING.md before touching anything, and start genuinely small.

An honest warning: contributing is slow and sometimes frustrating. PRs sit unreviewed for weeks, maintainers are overloaded and working for free, and sometimes your proposal is rejected for project-direction reasons you did not know about. None of that is personal. If you are after quick gratification, this is not the route; if you are after genuinely learning how software that other people use gets built, there is none better.

The term "cargo cult" comes from the practice of imitating the form of something without understanding its function. In this discipline it is endemic: people copying the pipeline structure of a large company without having either its problems or its resources.

It has equally identifiable markers:

• It states the context without being asked: "in a team of eight, with daily deployments and no formal on-call…".
• It mentions what it cost: "it worked, but it ate two weeks and we had to train the whole team".
• It includes the failure: "we tried it first with X and dropped it because…". Somebody who tells you what they removed has really operated the system.
• It distinguishes what they know from what they assume: "I have not tried it in that version, but it should…".
• It answers with a question before recommending anything. The first response from people who know is usually "how many of you are there and what is failing right now?".

The risk of this lesson is that you turn it into a list of subscriptions. The result would be the permanent feeling of being behind, which is the most common and most useless state of mind in the profession.

A diet that works:

• Depth, weekly. One long, substantial thing: a chapter from the 08-01 plan, a public post-mortem, an RFC. 45 minutes. It is the only item on this list that produces judgement.
• Currency, daily and limited. Fifteen minutes as a ceiling, and only for the tool you use in production: its release notes, its changelog, its security advisories. That is all you need to keep up with day to day.
• Radar, weekly. One pass through HN or r/devops or whichever newsletter, with an explicit rule: finding out that something exists is not a pending task. Note it on an "it exists" list and move on.
• Community, when you need it. Ask and answer when appropriate; do not live there.
• And one rule for discarding: if you have been seeing a name for six months and it has never solved a problem of yours, delete it from your radar. It will come back if it matters.

What to internalise about the hype cycle: the tools that genuinely matter will still be there in five years, and you will learn them then with better documentation, more examples and fewer rough edges. Arriving late to a good tool costs little; arriving early to a bad one costs a migration.

This is the only section of the lesson where a mistake has serious and potentially legal consequences.

When you ask for help, you paste logs. And pipeline logs contain, more often than people think:

• Credentials. Tokens in URLs, Authorization headers, connection strings with passwords, access keys in environment variables dumped by a debugging env.
• Infrastructure identifiers. AWS account IDs, ARNs, bucket names, RDS endpoints, internal IPs, OIDC role ARNs. Individually they look harmless; together they are a map for anyone who wants to attack you.
• Personal data. An integration test log can carry real names, phone numbers and email addresses if somebody populated the test environment with a production dump — a more common practice than is acceptable.
• Commercial information. Client names in paths, in branch names or in project identifiers.

Lesson 04-03 taught you the defensive mechanism: secrets are masked in CI logs, they are rotated when exposed, and Gitleaks detects them in the repository. But none of those defences acts when you copy and paste a log into a forum. GitHub Actions masking only covers the values registered as secrets in that repository, not a token some command printed on its own nor an ARN that was never a secret.

Protocol before publishing any log or configuration fragment:

1. Anonymise consistently. Replace with obvious placeholders (<ACCOUNT_ID>, arn:aws:iam::<ACCOUNT>:role/<ROLE>, company.example.com). Consistently means that the same real value is always the same placeholder; otherwise the problem stops being reproducible.
2. Do not invent plausible values. A fake but believable ARN might belong to a genuinely different company. Use example.com and <PLACEHOLDER>, which exist precisely for this.
3. Trim before anonymising, not after. The less text you publish, the less there is to review.
4. Read it through once more before hitting send, looking specifically for: password, token, key, secret, Authorization, Bearer, twelve-digit numbers and email addresses.
5. If in doubt, do not publish it. Describe the error in words.
6. And if you publish something by mistake: rotate the secret immediately and then delete the message. In that order. Deleting does not undo: the content may be in caches, in desktop clients, in notification emails and in third-party archives. The only effective action is invalidating the credential. Exactly what 04-03 said about a committed secret: it is not deleted, it is rotated.
7. Client data: never, under any circumstances. It is not a matter of prudence but of data protection regulation, and posting on a forum a log with the names and phone numbers of Reservalia's end clients is a reportable incident, exactly as constraint 4 of the 07-06 brief stated.

It applies in reverse too. If somebody posts a secret in a channel, tell them privately and immediately. Do not quote it, do not comment on it in public and do not use it. It is what you would expect them to do for you.

• Asking before searching. A huge proportion of questions are already answered on the first page of results. Searching first is not just politeness: it is faster than waiting for an answer.
• Searching only on Google and not in the issue tracker. A tool's recent problems are in its issues before they are in any blog. It is the place fewest people look and where the answer most often is.
• Confusing popularity with suitability. A tool dominating the conversation means a lot of people are talking about it, not that it solves your problem. The whole of module 6 was an exercise in separating those two things.
• Taking one space's consensus for the sector's consensus. Every community has its bias: a tool's forum defends it, r/devops complains about everything, HN prefers the new. Always triangulate across at least two different spaces.
• Consuming without ever giving back. Besides being unfair to the people who sustain all this, it is your own loss: answering is what fixes what you have learned. The first time you explain to somebody why you promote by digest, you will discover which parts you were not clear on.
• Pasting logs without reviewing them. The mistake in this lesson with real consequences. The section 9 protocol, always, even when you are in a hurry. Especially when you are in a hurry.
• Tip: keep your own answers. When you solve a hard problem, write it down somewhere searchable — your wiki, your blog, the forum. Your future self a year from now is the main beneficiary, and you help strangers along the way.
• Tip: choose two spaces and be consistent. Being present in two communities for a year builds real reputation and real contacts. Passing through ten for a month builds nothing.
• Tip: answer questions one level below yours. That is where you can help most and where you learn most, because it forces you to articulate what you know only approximately. You do not need to be an expert to help somebody who started three months ago.

A colleague posts this in the community channel:

"Hi all! I have a problem with Terraform, when I run apply it gives me a state lock error and I can't deploy. I've already tried everything, I even deleted .terraform. Anyone know how to fix it? Urgent, we have a release today."

Rewrite it so that it has a high chance of being answered. Invent whatever technical details are needed — staying consistent with the course's stack — and explicitly point out which information you have added and why each piece matters. Also add what you would say to your colleague about two specific things in their original message beyond the missing data.

In a thread about pipelines, somebody with a lot of followers writes:

"Golden rule: never use third-party actions in your workflows. Write everything yourself. It's what every serious company does, and anything else is a security breach waiting to happen."

Analyse the advice: which part has a real basis (connect it to the specific lesson in the course), which warning signs it shows, what context is missing, and how you would reformulate the advice to make it useful. Then decide what you would do in Mini-Reservalia and justify it.

Design your own information diet for the next six months, with a limit of three hours a week in total, and justify each choice according to your situation (you can use Nuria's if you prefer a concrete case: frontend/QA, wants to move towards delivery and operations, works in a team of three). Then choose one specific contribution you could make in the next two weeks to a project you already use, and describe the exact first step.

Solution 1

Rewritten question:

Subject: terraform apply fails with "Error acquiring the state lock" in DynamoDB after cancelling a run in GitHub Actions

Context. Terraform 1.7.5, S3 backend with DynamoDB locking. The infrastructure is applied from a GitHub Actions workflow with OIDC authentication. Yesterday I manually cancelled a workflow run that had got stuck in the apply.

Actual behaviour. Since then, any terraform apply — both from the workflow and from my machine — fails with:

Error: Error acquiring the state lock
Lock Info:
  ID:        9f3c1a2e-...
  Operation: OperationTypeApply
  Who:       runner@fv-az512-393
  Created:   2026-07-30 09:14:22 UTC

What I have checked:

1. There is no other workflow run in progress and no colleague applying.
2. The lock entry is still in the DynamoDB table, with the ID that appears in the error.
3. I deleted the local .terraform directory and ran terraform init again: nothing changes, which makes sense because the lock is remote and not local.

Hypothesis. Cancelling the job killed the process without giving it a chance to release the lock, and it was left orphaned.

Specific questions: (a) Is terraform force-unlock <ID> the correct way to resolve this, and what is the risk if the state was left half written? (b) How do I verify before forcing that the remote state is consistent? (c) Is there any way for the workflow to release the lock when it is cancelled?

What information has been added and why each piece matters:

The two things I would tell them beyond the data:

1. "I've already tried everything" and deleting .terraform are the same signal: they were trying actions without a model of the problem. Deleting the local directory in the face of a remote lock could never work, and knowing why it could never work is what would have taken them straight to DynamoDB. Before trying, formulate the hypothesis: "if the lock is in DynamoDB, what local action could possibly affect it?".
2. "Urgent, we have a release today" is counterproductive. It speeds nobody up — whoever answers does so for free and in their own time — and it does signal that they may receive badly calibrated emergency advice. And there is a concrete risk here: the quick answer is "just run force-unlock", which in the worst case — a half-written state — corrupts the remote state and turns a twenty-minute problem into a whole day. Being in a hurry is exactly the reason to ask well, not to ask badly.

Solution 2

What has a real basis. The concern is legitimate and the course shares it: 04-03 and 07-05 treat third-party actions as a real attack surface. An action is somebody else's code running on your runner, with access to the workspace, to the environment variables and potentially to your credentials. A compromised maintainer, or a version tag moved to a malicious commit, executes code in your pipeline. That is why the course's practice is to pin actions by full SHA, not by tag.

Warning signs, according to the table in section 8.1:

• "Never": an absolute with no condition. The honest version has conditions.
• "It's what every serious company does": an uncited appeal to authority, plus a circular definition of "serious". A great many competent organisations use third-party actions with controls in place.
• No trade-offs: it does not mention the cost of writing everything yourself, which is enormous and ongoing.
• No stated scale: it does not say what size of team it is talking about.

What context is missing. The decisive kind. In an organisation with a dedicated platform team, maintaining internal actions is viable and probably correct: the cost is amortised across dozens of teams and there is somebody to maintain them. In a team of three, writing and maintaining your own version of actions/checkout, setup-node or configure-aws-credentials means maintaining critical infrastructure code with nobody to review it or to update it when the platform changes. The most likely outcome is not more security: it is an unmaintained in-house action with older vulnerabilities than the ecosystem's. The advice, applied without context, makes worse exactly what it claims to improve.

There is also a critical distinction the advice flattens: not all third-party actions are the same. GitHub's official ones (actions/*), the cloud provider's (aws-actions/*) and those from projects with solid governance are not in the same risk category as an action from a personal repository with twelve stars and no commits in two years.

A useful reformulation:

"Every third-party action is somebody else's code with access to your pipeline. Before adding one, look at who maintains it, how often, and how many people depend on it. Always pin by full SHA, never by tag, and automate updating those SHAs with Dependabot or Renovate so that pinning does not mean falling behind. Give each job least privilege, so that a compromised action cannot do much. If you have a platform team and many repositories, consider maintaining your own internal actions for the critical parts; if there are few of you, writing them yourself usually turns out worse because nobody will maintain them."

What I would do in Mini-Reservalia. Keep using third-party actions, with the controls already in place since 07-05: full SHA on all of them, least privilege per job, Dependabot watching for updates and a preference for official actions or ones with clear governance. The small-team constraint makes writing everything in-house unviable, and the residual risk is mitigated by controls a team of three can actually sustain. That, with its date and its review condition, goes into PIPELINE.md: if one day there is a platform team, it gets reassessed.

Solution 3

Nuria's diet, three hours a week:

Total: about 2 h 45 min, with room to spare. What is deliberately excluded: daily newsletters, Twitter/X and LinkedIn as a source of learning, and anything about tools Nuria does not use. With three hours a week, every minute spent on something that does not touch her work is a minute not spent on something that does.

First contribution, with the exact first step. Playwright documentation or that of a GitHub Actions action related to E2E testing.

Exact step for the next two weeks: the next time she follows the Playwright documentation to configure something — parallelisation, retries, CI reports — and finds an example that does not work as written, a missing step or an ambiguous sentence, note it down there and then (this is what gets lost: the next day you no longer remember it). Then, find the project's documentation repository, read its CONTRIBUTING.md in full, check whether there is already an open issue about it and, if not, open a PR with the minimal correction and a description of what happened to her while following the document.

Why this one and not another: it is low risk — a documentation change cannot break anybody's product — it takes advantage of her newcomer's perspective before it wears off, and it teaches her the full contribution flow (fork, branch, PR, review, requested changes, merge) on a trivial change. The second contribution, with the flow already known, can be more ambitious.

The difference between the person who stays blocked for three days and the person who solves it in two hours is almost never talent. It is knowing that the problem is one of context, knowing which space that context lives in, and knowing how to ask in a way that saves work for whoever answers.

The essentials of this lesson:

• There are three types of problem and only the context one requires a community. The other two are solved by reading and by practising, and confusing them wastes everybody's time.
• Every space has its declared bias: official forums are precise about their tool and partial about the others; Stack Overflow is an excellent, ageing archive; Slack is fast and ephemeral; Reddit measures frustration; HN measures novelty; LinkedIn is marketing. Always triangulate.
• The definitive truth is in projects' issues and RFCs, which are the worst-indexed and most reliable source there is.
• Asking well is a technique with identifiable parts: a searchable subject, expected versus actual, a minimal reproducible case, versions, what you have tried with its results, your own hypothesis and a specific question. And it frequently solves the problem before you post it.
• Contributing from day one is possible and it is the fastest learning route: reproducing issues, documentation, examples, translations, reviewing PRs. You do not need to be an expert; you need to have tripped over something.
• Information hygiene is defended with questions: in what case would it not apply?, what do you lose?, how big was your team? Absolutes, appeals to authority and advice with no trade-offs are warning signs.
• And you never post a log without reviewing it. Anonymise consistently, reread looking for credentials and personal data, and if something slips through: rotate first, delete afterwards.

The books in 08-01 give you the foundation and the communities in this lesson give you the context. The third piece is missing: the specific tools the course touched on or left out and that solve problems you now know how to recognise — managing secrets outside the repository, automating the canary you configured by hand in 03-04, validating policies before applying infrastructure, measuring the supply chain with a framework of levels.

That is 08-03: Additional Tools and Plugins. And it is presented by problem, never by fashion: exactly the hygiene you have just learned to apply to other people's advice, now applied to tools.