DEV Community: Mykhailo

Cilium Certified Associate: I Scored 82, and eBPF Was Only 10% of It

Mykhailo — Sun, 01 Nov 2026 11:54:19 +0000

I wrote the longer version with the full domain breakdown and my prep notes on my blog.

Most people study for the Cilium Certified Associate like it's an eBPF exam. eBPF is 10% of it.

I passed the CCA on my first attempt with 82 (passing is 75). Of the 15 CNCF certifications on my way to Golden Kubestronaut, this is the one where my networking background helped the least.

Study to the weights

60 multiple-choice questions, 90 minutes, online proctored. The official Linux Foundation weights:

Domain	Weight
Architecture	20%
Network Policy	18%
Service Mesh	16%
Network Observability	10%
Installation and Configuration	10%
Cluster Mesh	10%
eBPF	10%
BGP and External Networking	6%

Architecture, Network Policy and Service Mesh are 54% together. eBPF is about six questions. I see people (me included, partly) pour hours into eBPF internals and BGP while under-preparing Service Mesh, which is worth nearly three times as much as BGP.

Identity, not IP

Cilium runs eBPF programs in the Linux kernel, with no iptables and no kube-proxy required. That's why the CKA only carries you part of the way here. Start with the fundamentals anyway, because the bigger domains assume them:

eBPF programs are checked by the verifier at load time. No infinite loops, no invalid memory access.
eBPF maps are key-value stores in kernel memory, shared between programs and user space. Cilium uses them for policy enforcement and flow tracking.
Every workload gets a numeric identity derived from its pod labels, and policy is enforced on that identity.

If one idea decides your score, it's the third one. The wrong answer is usually some version of "the policy uses the pod's IP". Pod IPs change on every restart, and Cilium's model exists to avoid that dependency. Also know that cilium-agent runs on every node, manages the eBPF programs and maps there, and talks to the Cilium operator.

L7 policy needs Envoy

A CiliumNetworkPolicy with HTTP rules looks like any other YAML:

ingress:
  - fromEndpoints:
      - matchLabels:
          app: frontend
    toPorts:
      - ports:
          - port: "8080"
            protocol: TCP
        rules:
          http:
            - method: GET
              path: /api/v1/.*

Nothing in it tells you those rules silently depend on the Envoy proxy being deployed. The exam gives you a scenario where HTTP filtering doesn't work and asks why. Envoy isn't there.

CiliumNetworkPolicy is namespaced. CiliumClusterwideNetworkPolicy has no namespace and covers the whole cluster. The scenario usually hints at which one it wants.

Service Mesh is where I lost points

I walked in thinking "network policy is network policy" and got hit by questions on transparent encryption modes and certificate-based mutual authentication. That's probably where most of my missing points went.

WireGuard, IPsec and mutual auth are all fair game. I'm not sure whether the exam goes deep on comparing the two encryption modes or only checks that you know both exist. I'd read both sections of the Cilium Service Mesh docs rather than gamble.

Hubble and kube-proxy replacement

Know the per-node Hubble server inside cilium-agent versus Hubble Relay, which aggregates flows across the cluster. Without Relay, hubble observe only shows the local node, and that exact situation is a question. Drill the filters from the Hubble docs: --namespace, --label, --verdict DROPPED, --type l7 --protocol DNS.

With kube-proxy replacement, service lookup goes from O(n) iptables chain traversal to an O(1) map lookup. Know Direct Server Return (responses bypass the load balancer) and when it helps. Skim the IPAM modes and what Cluster Mesh does across clusters while you're there.

Two weeks of prep

About 8 hours went into the free Isovalent labs, which I think are the best resource for this exam: real Cilium clusters with real eBPF in the browser. Do every lab tagged CCA. After each one I wrote the main commands or YAML from memory right away. Reading lab output didn't stick for me, recall did.

Reading the Cilium docs top to bottom didn't work. I spent two hours in the BGP section before realizing it's a small part of a 6% domain. The official CCA study guide maps topics to domains and is a better way to decide what to read.

Result

82, first attempt. The security side cost me points, and the eBPF and Hubble sections gave them back.

I put together a free CCA practice test for my own final review: questions across all eight domains in the same multiple-choice format as the real exam. Use it early, while there's still time to do labs for your weak domains. Sets for the other CNCF exams are at yetmike.com/tests, and my study links for the whole Kubestronaut path live in awesome-kubestronaut.

I only started thinking of Cilium as a kernel platform after the exam. Now I wonder how many of my Service Mesh mistakes were architecture mistakes in disguise.

Originally published on yetmike.com

Passing the OTCA With 83: Half the Exam Is the SDK Pipeline

Mykhailo — Sat, 31 Oct 2026 14:17:50 +0000

I wrote the longer version, with everything I read and what wasted my time, on my blog.

You can run Prometheus perfectly in production and still fail the OTCA.

If you've turned on auto-instrumentation or shipped telemetry to a Collector sidecar, you were inside the OpenTelemetry pipeline without ever being tested on how it works. The OpenTelemetry Certified Associate tests what happens inside it. I passed with 83 on the first attempt, one of the 15 CNCF certifications I did on the way to Golden Kubestronaut.

Format and weights

60 multiple-choice questions, 90 minutes, pass at 75%.

Domain	Weight
The OpenTelemetry API and SDK	46%
The OpenTelemetry Collector	26%
Fundamentals of Observability	18%
Maintaining and Debugging Observability Pipelines	10%

Nearly half the exam is SDK internals, the part most people never read because the library works once you add it.

Don't study backends

Prometheus, Grafana and Jaeger are out of scope. OTCA covers the layer in front of them: how code produces a span, where it travels inside the SDK, and what the Collector does with it next. It's language-agnostic too, so no Go or Python syntax. The OTel Operator gets a mention, but I didn't see it tested in depth.

The SDK domain

Fundamentals (18%) is cheap points if you know what a trace is, what a metric data point looks like and why semantic conventions exist.

The SDK domain is harder in a specific way. Questions ask which layer owns a behavior, and the wrong options are real OTel concepts placed one layer up or one layer down. The model I'd build first:

Providers. TracerProvider, MeterProvider, LoggerProvider, one entry point per signal.
Processors transform or batch data. Know BatchSpanProcessor versus SimpleSpanProcessor.
Exporters (OTLP, Console, Zipkin) are where data leaves the SDK.

Then the API versus SDK split from the specification overview: the API defines interfaces, the SDK implements them. I had been treating them as one thing, and that costs a handful of easy questions.

File-based SDK configuration is tested as well. Provider contains processor contains exporter, and once you see that nesting the config questions get much easier.

Context propagation

I think people skip this, and it shows up more than you'd expect. In-process, Baggage and SpanContext flow through the language's Context API. Across processes it's W3C Trace Context: the traceparent header and what each field holds. B3 is older and still appears in questions, so learn it even if you've never configured it.

The Collector is a full pipeline

26% of the exam, and most engineers treat the Collector as something you drop in and forget. Receivers accept data, processors transform it, exporters send it, all wired as named pipelines under service.pipelines. One config can hold separate pipelines for traces, metrics and logs.

Processor order is a real topic:

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [otlp]

memory_limiter goes first so the Collector can shed load before it gets OOM-killed. batch goes last before export to cut outbound requests. Flip them and the config can fall over under load. I got those questions right only because I had read the Collector configuration docs.

Know agent mode (one Collector per node, DaemonSet or sidecar) and gateway mode (a central cluster aggregating from agents or SDKs). Tail sampling in gateway mode needs careful routing, because related spans must land on the same instance.

Debugging (10%) is small. Learn the common patterns and move on.

What worked and what didn't

I started with LFS148, the free Linux Foundation OpenTelemetry course. That's where API versus SDK finally clicked. Then the official docs with a notepad, writing down what each component owns: about six hours over three sessions.

The OTel Demo app is underrated for this. Running it locally and reading its SDK configs taught me more about the Collector than any tutorial.

Two things wasted my time. Language-specific SDK examples cost me two hours on an exam with no syntax in it. Third-party Collector scaling articles were the other, since some referenced patterns that changed between versions.

Where my 83 came from

Mostly SDK pipeline questions, where I spent the most time, plus Collector processor ordering. If you want to check where you stand before booking, the OTCA practice test I built during prep covers every topic above. Tests for other CNCF exams are at yetmike.com/tests, and the rest of my study links are in awesome-kubestronaut.

I still feel shaky on Collector scaling. I passed, but I'm not convinced the third-party material I read on it was current.

Originally published on yetmike.com

Prometheus Certified Associate: How PromQL Decides Whether You Pass

Mykhailo — Fri, 30 Oct 2026 21:46:00 +0000

I wrote the longer version, with more on each domain, on my blog.

PromQL is 28% of the Prometheus Certified Associate exam, and it's the domain that fails people. I've seen engineers who run Prometheus in production every day pick the wrong function under exam pressure, and I was almost one of them.

I passed with 82 out of 100 on the first attempt. Passing is 75, and most of the points I nearly lost were on things I thought I already knew from work.

Format and domains

From the Linux Foundation curriculum: around 60 multiple choice questions, 90 minutes, 75% to pass, online proctored, no hands-on part.

Domain	Weight
PromQL	28%
Prometheus Fundamentals	20%
Observability Concepts	18%
Alerting and Dashboarding	18%
Instrumentation and Exporters	16%

After PromQL the weights are flat. Fundamentals plus Observability is 38%, Instrumentation plus Alerting another 34%. There's no throwaway domain.

Underneath it all, the PCA checks whether you understand the data model: Prometheus is a time series database where every metric is a set of labeled samples. If that feels abstract, PromQL will feel random.

PromQL

The exam hands you an expression and asks for the output, or describes a scenario and asks which expression matches. You only get good at that by writing queries.

The classic trap is rate() vs irate(), placed side by side and written to look interchangeable:

rate(http_requests_total[5m])   # per-second average over the full 5m window
irate(http_requests_total[5m])  # only the last 2 samples

rate() smooths short spikes, which is what you want for alerts and dashboards. irate() reacts instantly and is jumpy. A question describes a brief spike and asks which function reflects it: irate() shows the jump, rate() averages it away. I used rate() at work for years and had never checked how irate() differs until I studied.

Label matchers are everywhere:

{job="node_exporter"} is an exact match
{job=~"node.*"} is a regex match
{job!~".*test.*"} excludes anything containing "test"

sum(http_requests_total) by (job) keeps only the job label. sum(http_requests_total) without (instance) drops instance and keeps the rest. The questions hinge on which labels survive, so sketch the label set before and after on scratch paper.

histogram_quantile() needs a _bucket series with an le label. I think it's the one advanced function worth running once against real data.

Fundamentals

Prometheus pulls. It scrapes targets on an interval, and push vs pull came up more than once. The Pushgateway is the narrow exception for short-lived batch jobs that finish before a scrape. Using it as a general push endpoint for long-running services leaves stale metrics behind, and the exam tests that distinction.

Kubernetes service discovery is on there too. Remember relabeling: it turns the raw discovery labels into the final label set on your metrics.

Metric types

The four metric types were the most common non-PromQL topic I saw:

Counter only goes up and resets on restart. You wrap it in rate(), which is why rate() exists.
Gauge goes up and down. Read it directly.
Histogram exposes _bucket, _sum and _count, and the quantile is calculated on the server at query time, so it aggregates across instances.
Summary calculates quantiles on the client, and those can't be aggregated afterward. Expect a question on that trade-off.

Naming is tested directly: _total for counters, base units like _seconds and _bytes. Read the naming conventions once.

Alerting

Three things earned me points. An alert with for: 10m only fires if the condition holds for 10 continuous minutes. Recording rules pre-compute an expensive query into a new series. And who does what: Prometheus evaluates rules, Alertmanager groups, silences and routes, Grafana draws dashboards.

How I prepared

Three days of nothing but PromQL. Local Prometheus, node_exporter scraping my own laptop, real queries against real data. I kept going until I could predict the output before hitting enter. Nothing else came close.

Then the configuration docs and the alerting rules page, since the exam uses their exact field names. Then metric types and naming until they were automatic. For drilling functions away from a terminal, I made free PromQL flashcards.

Blog-post prep guides didn't help me much; most stay shallow and leave you stranded on PromQL. Paid courses exist, but I'd treat any of them as a supplement to writing queries yourself.

The order I'd use again:

Prometheus and node_exporter locally. PromQL every day.
Metric types and naming.
Pull model, Pushgateway, service discovery, relabeling.
Alerting rules, recording rules, Alertmanager vs Grafana.
Practice questions to find what's still weak.

For step 5, I built a free PCA practice test. It's PromQL-heavy on purpose and covers metric types and alerting too, so you see your weak domains before exam day.

Thinking in label sets

At some point I stopped thinking "query the database" and started thinking "transform a set of labeled time series." Now I ask what an aggregation does to the labels before I ask about the numbers, and the questions stopped feeling random.

The PCA was part of my Golden Kubestronaut path, 15 of 15 CNCF certifications. The study material I collected is in awesome-kubestronaut.

I'm still not sure how much of my 82 came from production experience and how much from those three days of queries. My guess is the three days mattered more than I'd like to admit.

Originally published on yetmike.com

Kyverno Certified Associate (KCA): where I lost points and how I'd prepare

Mykhailo — Sun, 18 Oct 2026 12:33:11 +0000

I wrote the longer version, with the full study order and every trap I hit, on my blog.

I passed the Kyverno Certified Associate on the first attempt with 85 out of 100. The policy YAML was the easy part. Every point I dropped came from not knowing exactly what runs where, and what blocks what.

It was one of the 15 CNCF certs I did on the Golden Kubestronaut track.

No Rego, no DSL

With OPA Gatekeeper you learn Rego first, a separate query language, before you can write anything useful. Kyverno skips that step. A policy is a Kubernetes resource with a spec block, applied with kubectl apply. If you can write a Deployment, you can read a Kyverno policy on day one.

So I think the KCA is a YAML exam with an architecture question hiding inside it, and prep is faster than most material suggests.

Format and domains

60 questions, 90 minutes, multiple choice, 75 to pass.

Domain	Weight
Writing Policies	32%
Fundamentals of Kyverno	18%
Installation, Configuration & Upgrades	18%
Kyverno CLI	12%
Applying Policies	10%
Policy Management	10%

Policy Management at 10% looks skippable. I gave it about an hour and still lost a question there.

Policy types (and the bit I'm unsure about)

Validate is the admission gate and holds most of the 32%. Audit reports a violation, Enforce blocks the request, and that split comes up again and again. Mutate changes resources on the way in with a strategic merge patch or JSON patch. Generate creates a resource in response to an event, like a default NetworkPolicy when a namespace appears. Cleanup deletes resources. Image verification checks signatures with Cosign.

Kyverno is mid-transition. Most tutorials still use ClusterPolicy, where every type lives as a rule inside one policy. The official docs now show the CEL based per-type resources like ValidatingPolicy, and ClusterPolicy is marked for deprecation. I studied the new ones, but I can't promise every question I saw used the new syntax. Know both shapes well enough to recognise them.

Mechanics worth drilling: match/exclude with any (OR) and all (AND), the anchors (), ^(), =() and X(), ClusterPolicy vs namespaced Policy, and autogen (a Pod rule gets Deployment, DaemonSet, Job and CronJob rules generated for you).

Admission controller vs policy controller

The exam keeps coming back to this.

The admission controller sits on the request path as a dynamic admission webhook. Validate and mutate run there. Because it's inline, a webhook failure becomes a cluster problem, which is why failurePolicy exists and gets asked about.

The policy controller runs off the request path: background scans, generate, cleanup. Background scans produce PolicyReport and ClusterPolicyReport. If it goes down, workloads keep running and nothing gets blocked.

Expect "which component handles this" and "what breaks when this is down". I'd derive both from the architecture in how Kyverno works rather than memorize a table.

The CLI is the cheapest 12%

kyverno apply policy.yaml --resource resource.yaml
kyverno test .

kyverno apply tells you whether a resource passes or fails. kyverno test runs a manifest of expected outcomes across several resources. Keep both running the whole time you study.

Where I lost points

Audit vs Enforce. Both look right when the question asks which one blocks admission. Enforce blocks.
Background scan vs admission time. The wrong option is always the other one.
Old vs new syntax. Stale ClusterPolicy patterns look correct on a multiple choice screen.

How I'd prepare

Reading docs gives you recognition, and a timed exam with four plausible answers punishes that. What worked for me was writing a policy, running a resource through it, breaking it on purpose, fixing it. About 20 rounds with kyverno apply in a loop. After that I didn't need to memorize Audit vs Enforce because I'd watched both happen. Passive video courses didn't work for me.

Start with the Kyverno introduction, then the per-type pages. The docs are good, which I don't say often.
Spend most of your time on Writing Policies with the apply loop. About a week if you build real policies.
Learn the controller split until "what breaks if this goes down" needs no thought.
Give Policy Management its hour. Maybe more than I did.
Run a practice test before booking. I put every scenario I built during prep into a free KCA practice test that shows which domain is still weak.

The rest of my study links live in awesome-kubestronaut.

Two questions for every answer

Does this run on the request path or off it? Does it block, or only report? Validate and mutate are on the path; generate, cleanup and background scans are off it. Once I had that, I worked answers out from where the thing sits.

85 left me 10 points of headroom, and I still got caught by a Policy Management question in the domain I just told you not to skip.

I don't know how long the classic ClusterPolicy questions stay in the pool. If you sit it soon, I'd like to hear which syntax most of your questions used.

Originally published on yetmike.com

Certified Backstage Associate: I Passed by Five Points

Mykhailo — Wed, 14 Oct 2026 21:57:53 +0000

I wrote the longer version, with every config detail I studied and the full prep timeline, on my blog.

I scored 80 on the Certified Backstage Associate exam. Passing is 75.

No single domain sank me. I gave two or three soft answers in each of the four domains, and they stacked up until I was a couple of bad guesses away from a retake. CBA takes a point here and a point there, wherever you were pretty sure instead of certain.

Why CNCF exam habits don't help

CBA was one of my last exams on the Golden Kubestronaut track. Other CNCF certs test you on operating something. CBA is 60 multiple choice questions in 90 minutes about how a framework works. No kubectl, no cluster to fix.

The wrong answers are written to catch people who learned Backstage by osmosis. I felt confident going in.

What made it click: Backstage is a TypeScript framework you build on and own. Once I stopped thinking of it as a wiki with plugins and treated it as a platform for building platforms, the plugin and architecture questions started to make sense.

Domain	Weight
Customizing Backstage	32%
Backstage Development Workflow	24%
Backstage Infrastructure	22%
Backstage Catalog	22%

Customizing Backstage (32%)

Mostly: what's a frontend plugin and what's a backend plugin.

Frontend plugins are React components. They run in the browser, register routes, show up in the sidebar, and talk to backend plugins over HTTP. Backend plugins are server-side, independent services with their own database connections, exposing REST or GraphQL APIs. Expect questions on where code runs, plugin registration and what App.tsx does (it wires plugins together).

Smaller items: Material UI is the UI library (not Tailwind, not shadcn), and extension points let modules hook into existing plugins without forking them.

Development Workflow (24%)

Three commands matter:

npx @backstage/create-app@latest
yarn dev
yarn build && yarn build-image

The first scaffolds a monorepo with the frontend app and backend together. yarn dev runs both in watch mode. yarn tsc is a separate step from building the Docker image, and the exam asks where each step fits, including where yarn install sits relative to yarn tsc.

Infrastructure (22%)

PostgreSQL is for production, SQLite for development only. The exam will offer answers that present SQLite as production-ready.

The backend uses Knex, and each plugin gets its own logical database. Cache backends (memory, Redis, Memcached) are in scope too.

The rest is mostly app-config.yaml, which is layered. app-config.yaml is the base, app-config.local.yaml and app-config.production.yaml sit on top, and later files override earlier ones. Secrets come from environment variables via ${...} substitution. Know the integrations, backend.database and catalog.locations blocks.

Catalog (22%)

Small weight, subtle distinctions. The entity descriptor format is tested directly:

apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: my-service
  annotations:
    backstage.io/techdocs-ref: dir:.
spec:
  type: service
  lifecycle: production
  owner: team-a
  system: my-system

Know every kind: Component, API, System, Domain, Resource, Group, User, Location. Confusing Component with API is the most common way to drop catalog points. Well-known annotations carry meaning and point at external systems (backstage.io/techdocs-ref, github.com/project-slug), while labels are plain key-value pairs for filtering. Entities arrive through a static catalog.locations entry or through discovery providers.

I underestimated ingestion troubleshooting most. You register an entity and it doesn't show up: invalid YAML, wrong apiVersion, missing required fields, a processing error in catalog-backend. All in scope, and "I think I know" won't get you through it.

How I prepared, and what I'd change

About 6 hours on the official docs first, starting with the architecture overview and then the catalog and plugin pages linked above. Then LFS142 from the Linux Foundation, which is free and covers the material at the right depth. I did it in one sitting, maybe 3 hours. I think it beats most third-party courses because people who work on Backstage wrote it.

My Kubernetes knowledge didn't carry over; I caught myself applying k8s mental models to catalog questions.

The bigger mistake was quieter. I read each domain until it felt familiar, then moved on. On exam day "I've seen this" wasn't enough, and that gap is where my soft answers came from. Next time I'd drill each domain until I could answer from memory.

That's why I built a free CBA practice test. It's catalog-heavy on purpose and shows you the difference between "familiar" and "certain" before the exam does. The other CNCF practice tests use the same approach, and the rest of my resources live in awesome-kubestronaut.

If I sat it again, I'd bank the easy points fast (entity kinds and spec fields, the three commands, frontend vs backend scope) and spend the remaining prep on ingestion troubleshooting and annotations vs labels.

I still can't settle the dev workflow question. Backstage ships so often that I'm not certain what I studied matches what you'll get. If something in that domain surprised you recently, I'd like to hear about it.

Originally published on yetmike.com.

Three cargo errors that don't happen any more

Mykhailo — Tue, 13 Oct 2026 23:29:07 +0000

Three of the cargo errors I sat down to document don't happen any more. I only found out because the build refused to publish the pages.

The setup: I'm generating one page per diagnostic for a Rust learning site, and every page has to be confirmed by a real toolchain before it ships. For the cargo corpus that means an entry is a whole project, not a snippet. A build script writes the file map into a temp dir, runs actual cargo in it, and compares what came back against what the page claims. If the two disagree, the entry doesn't exist.

31 cargo entries survived. Here are the three that didn't, on cargo 1.96.0.

A manifest with no version

[package]
name = "probe"
edition = "2021"

I wrote this expecting a parse failure naming the missing package.version. What I got:

   Compiling probe v0.0.0 (/tmp/probe)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 3.25s

It builds. version is optional now and defaults to 0.0.0, which cargo prints right there in the compile line if you're reading it. The error still fires for a missing name, so the neighbouring entry in my corpus is fine:

error: failed to parse manifest at `/home/you/project/Cargo.toml`

Caused by:
  missing field `package.name`

Name and version used to fail the same way. They don't now, and I'd have written that they do.

A misspelled key in [profile.release]

[profile.release]
opt-levle = 3

warning: unused manifest key: profile.release.opt-levle
   Compiling probe v0.1.0 (/tmp/probe)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.09s

A warning, and a build that succeeds with the default opt-level. This is the one I'm least happy about losing, because the failure mode is worse than an error would be. Your release build is not optimised the way you asked and the only evidence is one line that scrolls past. An error would at least stop you.

The typo case that does still error is a required key, and the message is worth looking at:

[package]
naem = "probe"
version = "0.1.0"

error: failed to parse manifest at `/home/you/project/Cargo.toml`

Caused by:
  missing field `package.name`

Cargo tells you what's absent, not what you misspelled. naem is sitting right there on line 2 and never gets mentioned.

A virtual manifest with one member

[workspace]
resolver = "2"
members = ["app"]

cargo run in that root, I was told, refuses because the root defines no package. It doesn't:

   Compiling app v0.1.0 (/tmp/probe/app)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.09s
     Running `target/debug/app`
hello from app

One member with a binary means one answer, so cargo picks it. Add a second member and the old error comes back, which is the version I kept:

error: `cargo run` could not determine which binary to run. Use the `--bin` option to specify a binary, or the `default-run` manifest key.
available binaries: app, tool

So the entry isn't wrong so much as it needed a workspace big enough to be ambiguous. That's a different page from the one I'd planned to write.

Why I'd have got all three wrong

I didn't reason my way to these. I lifted them from what I'd read, and what I'd read was written when they were true. I haven't gone back to count how many of those write-ups are still near the top of a search for the error text, so I'm not going to give you a number, but the phrasing is still out there in blog posts and answers and nothing about a stale answer looks stale.

Documentation of an error is a claim about behaviour at a point in time, and cargo keeps relaxing things. Each relaxation turns a correct old page into a confident wrong one. Nobody edits the old page, because nothing tells them to.

The gate is the whole value here. It's about 200 lines that shell out to cargo and diff two strings, and its only real job is telling me to delete something. Three pages I'd have sworn were correct, deleted before anyone read them, by a script with no opinions.

What I'm less sure about: I now have three documented non-errors and nowhere to put them. The page that says "this used to fail and doesn't" is probably more useful than the page that says "this fails", because it's the one that contradicts what you already read. But it isn't a diagnostic, and the site is organised entirely around diagnostics. I haven't worked out where it goes: https://codecrab.app/?r=devto-cargo-stale

CAPA Exam Guide: Argo CD Is Only a Third of It. I Scored 93

Mykhailo — Tue, 13 Oct 2026 23:20:24 +0000

I wrote the longer version, with more on each Argo project and my prep timeline, on my blog.

Daily Argo CD use covers about a third of the CAPA exam. You blast through the CD questions, and then Argo Events shows up.

I passed the Certified Argo Project Associate on the first attempt with 93 out of 100 (passing is 75). I don't run Rollouts or Events at work, so that score came from noticing early that I was preparing for the wrong exam.

Format and weights

60 questions, 90 minutes, all multiple choice. No terminal. If you've done CKA or CKAD, muscle memory won't help here.

Argo is four projects, each with its own object model, and you can't reason from one to another. The weights when I took it:

Domain	Weight
Argo Workflows	36%
Argo CD	34%
Argo Rollouts	18%
Argo Events	12%

Workflows is the biggest domain and the one most people underprepare. Check the official CNCF curriculum before you plan, in case the weights have moved.

Workflows (36%)

Argo Workflows runs DAGs in pods. Know dag templates versus steps templates cold. In a DAG template you declare dependencies explicitly: task B waits on task A because you wrote dependencies: [build], not because it's listed second. Steps run top to bottom with no dependency graph. The exam gives you a manifest and asks which style it is.

Parameters pass values between tasks, artifacts pass files. Run one real workflow and most of this domain comes for free.

Argo CD (34%)

The one people think they already know.

prune: true deletes cluster resources that were removed from Git. selfHeal: true reverts manual changes made directly in the cluster. The exam asks about each separately, and if you've only ever turned on automated sync with both set to true, you've never had to think about which does what.

Sync status and health status are separate axes. Synced vs OutOfSync says whether the cluster matches Git. Healthy, Progressing, Degraded or Missing says whether the thing works. An app can be Synced and Degraded at once, and that combination gets tested.

Also recognize sync waves and hooks (PreSync, Sync, PostSync; the lowest wave applies first), ApplicationSet (one template plus generators makes many Applications), app-of-apps, and AppProject as the RBAC boundary. Know what each is for. You don't need to write them from memory.

Rollouts (18%)

Argo Rollouts replaces a Deployment when you need canary or blue/green.

Canary splits live traffic by percentage. Both versions serve users at the same time, and an AnalysisRun gates whether traffic keeps increasing.
Blue/green stands up a full second environment and swaps all traffic at once via activeService and previewService. Rollback is switching the Service back, because the old version is still running.

The wrong answer usually blurs "both versions live" with "instant full cutover".

Events (12%)

Only 12%, but it's where I burned the most prep time, and most of us have never touched anything like it at work.

In Argo Events, the EventSource listens to the outside world: a webhook, a file landing in S3, a Kafka message, a schedule. The Sensor subscribes to it and decides what to do. The Trigger is the action, like submitting a Workflow, creating a resource or calling an endpoint. Underneath, the EventBus (backed by NATS) carries events between EventSource and Sensor.

EventSource listens, Sensor decides, Trigger acts. I said that chain out loud probably 20 times before it stuck, because under pressure the instinct is to assume the listener is also the decider.

Even with the model down, Sensor dependencies and trigger conditions took me longest per question.

How I prepared

Two weeks: one of study, one of practice tests.

For each project, before opening docs, I wrote down the problem it solves and its three main objects. That exposes the gaps that reading lets you nod past.

I also deployed all four projects on one cluster. Not production grade, just enough to watch a workflow run and a rollout progress.

What didn't work: going deep on Argo CD because I use it daily and skimming Events. About five days in I caught it and moved my time over.

The easy points are the OpenGitOps principles, the Workflows template types (container, script, dag, steps), and knowing which Argo project solves which problem.

Beyond the official docs, the Linux Foundation has LFS256, DevOps and Workflow Management with Argo, and everything I used for all 15 CNCF certs is in awesome-kubestronaut.

Practice test

I built a free CAPA practice test around the traps that cost the most points (EventSource/Sensor, selfHeal vs prune, canary vs blue/green, DAG vs steps). Take it a week out and you'll see which domain needs your last few evenings. Other CNCF exams are at yetmike.com/tests.

Two weeks was enough. I'm not sure I'd pass the Events section again without a refresher, though. Sensor conditions only stick if you run them, and I don't run Events outside a practice cluster.

Originally published on yetmike.com.

Every rustc error has two spans, and they mean different things

Mykhailo — Sat, 03 Oct 2026 21:13:39 +0000

The line rustc points at is usually not the line you edit. The message is doing more work than most people read.

Here's the smallest example, E0384:

fn main() {
    let x = 5;
    x = 6;
    println!("{x}");
}

error[E0384]: cannot assign twice to immutable variable `x`
 --> src/main.rs:3:5
  |
2 |     let x = 5;
  |         - first assignment to `x`
3 |     x = 6;
  |     ^^^^^ cannot assign twice to immutable variable
  |
help: consider making this binding mutable
  |
2 |     let mut x = 5;
  |         +++

Two spans. Line 3 carries the carets, because that's where the rule broke. Line 2 carries a single dash, because that's where you made the decision that broke it. The header names the failure, the dash names the cause, and the help: block edits the cause, not the failure. Read in that order the error stops being a complaint and turns into a two line story: you decided here, it went wrong there.

Most people stop at the header, add mut, and keep going. That works for E0384 and it teaches you nothing that survives to the next error.

The same shape, one step harder

E0382, borrow of moved value:

fn main() {
    let name = String::from("crab");
    let other = name;
    println!("{name}");
}

error[E0382]: borrow of moved value: `name`
 --> src/main.rs:4:16
  |
2 |     let name = String::from("crab");
  |         ---- move occurs because `name` has type `String`, which does not implement the `Copy` trait
3 |     let other = name;
  |                 ---- value moved here
4 |     println!("{name}");
  |                ^^^^ value borrowed here after move
  |
help: consider cloning the value if the performance cost is acceptable
  |
3 |     let other = name.clone();
  |                     ++++++++

Carets at line 4. But nothing on line 4 is wrong in isolation, printing a String is fine. The dashes carry the actual content: line 2 says why the type behaves this way, line 3 says where the ownership left. The fix lands on line 3, one line above the report and two below the explanation.

That middle dash on line 2 is the whole ownership model in one sentence, and it's the part people skim because it's long and doesn't have carets under it.

And once more, with three

E0502:

error[E0502]: cannot borrow `numbers` as mutable because it is also borrowed as immutable
 --> src/main.rs:4:5
  |
3 |     let first = &numbers[0];
  |                  ------- immutable borrow occurs here
4 |     numbers.push(4);
  |     ^^^^^^^^^^^^^^^ mutable borrow occurs here
5 |     println!("{first}");
  |                ----- immutable borrow later used here

Here the second span split in two, one before the carets and one after. That's the borrow checker showing you a span of time, not a span of text: the borrow starts at line 3, is still alive at line 5, and line 4 sits inside it. Delete the println! and the error goes away, which is a strange thing to be true about code three lines up from the complaint.

So the rule generalises a little past "two spans". Carets are where the compiler stopped. Dashes are the evidence, and there can be one or several. The fix goes wherever the evidence points.

Why I think this matters more than the error codes

I've been writing one page per rustc error code and I'm about fifty in, out of roughly six hundred codes that exist. Somewhere around the twentieth it stopped feeling like fifty separate things to memorise. The codes differ, the span layout doesn't, and the layout is the part you can actually carry into an error you've never seen. A beginner who reads dashes before carets can handle E0499 the first time they meet it. A beginner who's memorised twelve codes still can't.

My unresolved doubt, and it's a real one: rustc --explain E0384 is already built into the toolchain, offline, with no site to visit. It explains the code in general. It does not explain your diagnostic, with your line numbers and your dashes in it, which is the thing I think people need. I'm not certain that gap is big enough to justify a page per code. I've got about fifty of them here if you want to tell me either way: https://codecrab.app/?r=devto-two-spans

What's the error you kept fixing at the wrong line before you noticed the dashes?

CGOA exam prep: why 50 clusters of Argo CD got me an 82

Mykhailo — Sat, 03 Oct 2026 20:47:34 +0000

I wrote the longer version, with the full domain breakdown and my prep timeline, on my blog.

I run Argo CD in production on 50 Kubernetes clusters across several public clouds. Before studying for the Certified GitOps Associate, I took a practice test cold and scored 82. Passing is 75, so fine on paper. The questions I missed were the ones I didn't expect to miss.

The CGOA does not grade how well you run Argo CD. It grades whether you can apply the OpenGitOps specification word for word.

Format

60 multiple-choice questions, 90 minutes, 75 to pass. No terminal, no kubectl, no YAML. Argo CD and Flux appear as examples, never as the thing being graded.

Domain	Weight
GitOps Principles	30%
GitOps Terminology	20%
GitOps Patterns	20%
Related Practices	16%
Tooling	14%

Tooling is roughly one question in seven. In my experience it gets most of people's prep time anyway, because sync options and CRDs are what we touch every day.

30% of the exam is four sentences

About 18 questions come from the four OpenGitOps principles:

Declarative. The system is described declaratively.
Versioned and Immutable. Desired state is stored in a way that enforces immutability and versioning, and retains a complete version history.
Pulled Automatically. Software agents automatically pull the desired state declarations from the source.
Continuously Reconciled. Software agents continuously observe actual system state and attempt to apply the desired state.

Memorize the exact wording. The options are written so a paraphrase lands you on the wrong one. "Pulled Automatically" is the usual slip: people read it as "applied automatically", but the agent pulls and the CI pipeline does not push.

Terminology cost me the most

Terminology is 20%, and the spec vocabulary sits in the question stem too, so a fuzzy term means you misread the question before you see the options.

Learn desired state, actual state, state drift, state store, reconciliation, feedback loop, rollback, and "continuous" (recurring, not instantaneous). The pair people mix up most: Git is the state store, the cluster holds the actual state.

My 82 came from here. I'd fixed plenty of state drift. I was sloppy about the exact definition.

Pull vs push, and related practices

In the pull model an agent inside the cluster watches Git and applies changes, so CI holds no cluster credentials. In the push model a runner calls kubectl apply or Helm. That deploys fine, and it isn't GitOps.

The wrong answer on a patterns question is usually a pipeline that deploys everything correctly. A couple caught me because I was thinking about implementation. Also know that a reconciler can run in-cluster or externally as long as it pulls, that the merge is the promotion, and that reverting the commit is the rollback.

Related Practices (16%) is mostly review with a DevOps background: Infrastructure as Code, Configuration as Code, DevSecOps, CI vs CD. In GitOps, CI builds and tests, the reconciler deploys. A few CI/CD split questions made me stop, and I'm not sure whether that section has shifted since I sat it. If you're preparing in late 2026, check the current curriculum first.

How I'd prepare

I spent about 8 hours over a weekend. Aimed right from the start, I think 5 or less.

Read the OpenGitOps principles and the GitOps glossary. About 20 minutes. Say the principles out loud without looking.
Take the free LFS169 Introduction to GitOps course. Around 4 hours, and it follows the exam domains in order.
Do practice questions until the wrong answers look obviously wrong. For this step I built a free CGOA practice test from the concepts I had to reason through after that 82, so you can see which domain is weak before exam day.

I wasted about 2 hours on Flux and Argo CD docs. Nobody cares about argocd app sync flags here. More study links are in awesome-kubestronaut.

The mental model

GitOps clicked when I saw it as a control loop rather than a deployment tool. Same pattern as a Kubernetes controller: watch desired state, compare to actual, reconcile. Desired state lives in Git instead of etcd.

The four principles then map onto the loop: how you express desired state, how you store it, how the agent gets it, what the agent does with it.

98 out of 100, first attempt. The concepts aren't hard; they need precision, which is probably why people with years of Argo CD keep landing around 80 first try.

I still don't know whether those Related Practices questions were bad luck or the curriculum drifting. If you sit it after me, tell me which.

Originally published on yetmike.com

The 22 Rust errors every beginner hits, in the order they hit them

Mykhailo — Sun, 16 Aug 2026 20:50:35 +0000

Rust's compiler is the best teacher in the language and almost nobody reads it properly. Below are the 22 errors you will actually hit, roughly in the order you'll hit them, with what each one is really telling you.

Every diagnostic here is real. It was captured from a real rustc 1.96.0 (ac68faa20 2026-05-25) compiling a real broken program. The explanations were drafted with an LLM and edited by me.

Two things to know before the list.

Most Rust errors underline two places. One is where the rule was broken. The other is where the decision that broke it was made. The error is reported at the first; the fix is almost always at the second.

The help: block is often a literal diff. When you see +++ under a span, rustc isn't describing the fix. It's writing it.

1. E0061: The function takes two arguments and you passed one.

error[E0061]: this function takes 2 arguments but 1 argument was supplied
 --> src/main.rs:6:20
  |
6 |     println!("{}", add(1));
  |                    ^^^--- argument #2 of type `i32` is missing
  |
note: function defined here
 --> src/main.rs:1:4
  |
1 | fn add(a: i32, b: i32) -> i32 {
  |    ^^^         ------
help: provide the argument
  |
6 |     println!("{}", add(1, /* i32 */));
  |                         +++++++++++

The fix. Pass both: add(1, 2).

Rust has no default parameters and no overloading, so arity is exact. That sounds restrictive until you notice it means a function signature is a complete description of how to call it. There is never a hidden second way.

2. E0277: `Vec` has no single obvious way to print itself, so `{}` will not take it.

error[E0277]: `Vec<{integer}>` doesn't implement `std::fmt::Display`
 --> src/main.rs:3:20
  |
3 |     println!("{}", numbers);
  |               --   ^^^^^^^ `Vec<{integer}>` cannot be formatted with the default formatter
  |               |
  |               required by this formatting parameter
  |
  = help: the trait `std::fmt::Display` is not implemented for `Vec<{integer}>`
  = note: in format strings you may be able to use `{:?}` (or {:#?} for pretty-print) instead

The fix. Use the debug formatter: println!("{:?}", numbers);

This is the first trait error most people meet, and the message names the exact missing capability: Vec<i32> doesn't implement std::fmt::Display. Read trait errors as a sentence (this type cannot do that thing) rather than as a wall.

3. E0282: Rust cannot work out what type this collection holds, because nothing was ever put in it.

error[E0282]: type annotations needed for `Vec<_>`
 --> src/main.rs:2:9
  |
2 |     let items = Vec::new();
  |         ^^^^^   ---------- type must be known at this point
  |
help: consider giving `items` an explicit type, where the type for type parameter `T` is specified
  |
2 |     let items: Vec<T> = Vec::new();
  |              ++++++++

The fix. Say it: let items: Vec<i32> = Vec::new();

Rust infers types from use, not from declaration. Push one integer and the annotation becomes unnecessary, because the inference works forward from evidence, and here you gave it none.

4. E0308: You promised an `i32` and returned nothing.

error[E0308]: mismatched types
 --> src/main.rs:1:14
  |
1 | fn five() -> i32 {
  |    ----      ^^^ expected `i32`, found `()`
  |    |
  |    implicitly returns `()` as its body has no tail or `return` expression
2 |     5;
  |      - help: remove this semicolon to return this value

The fix. Delete the semicolon after 5.

() is Rust's word for "nothing". Whenever you see found (), look for a stray semicolon before you look at anything else. In Rust an expression without a semicolon is the value, and with one it becomes a statement that evaluates to nothing.

5. E0381: The variable was declared but never given a value, and you read it.

error[E0381]: used binding `count` isn't initialized
 --> src/main.rs:3:16
  |
2 |     let count: i32;
  |         ----- binding declared here but left uninitialized
3 |     println!("{count}");
  |                ^^^^^ `count` used here but it isn't initialized
  |
help: consider assigning a value
  |
2 |     let count: i32 = 42;
  |                    ++++

The fix. Give it a value: let count: i32 = 0;

Other languages hand you a zero or a null here. Rust refuses to guess, and that refusal is the point: there is no such thing as an uninitialised read in safe Rust, so a whole category of bug cannot reach runtime.

6. E0384: `let` bindings do not change unless you say `mut`.

error[E0384]: cannot assign twice to immutable variable `x`
 --> src/main.rs:3:5
  |
2 |     let x = 5;
  |         - first assignment to `x`
3 |     x = 6;
  |     ^^^^^ cannot assign twice to immutable variable
  |
help: consider making this binding mutable
  |
2 |     let mut x = 5;
  |         +++

The fix. Write let mut x = 5;

Two spans, not one: the ^^^^^ is where the rule broke, the - marks where the decision was made. The error is reported at the assignment, the thing you change is the declaration. That pattern holds across most Rust errors, and once you see it you cannot unsee it.

7. E0425: You used a name that was never declared in this scope.

error[E0425]: cannot find value `count` in this scope
 --> src/main.rs:2:20
  |
2 |     println!("{}", count);
  |                    ^^^^^ not found in this scope

The fix. Declare it first: let count = 0;

Ninety percent of the time this is a typo, and rustc will often guess the name you meant in a help: line. Read that before you go looking for a real bug, because the compiler has already done the search.

8. E0596: You called a method that needs to modify the value, on a binding that cannot be modified.

error[E0596]: cannot borrow `numbers` as mutable, as it is not declared as mutable
 --> src/main.rs:3:5
  |
3 |     numbers.push(4);
  |     ^^^^^^^ cannot borrow as mutable
  |
help: consider changing this to be mutable
  |
2 |     let mut numbers = vec![1, 2, 3];
  |         +++

The fix. let mut numbers = vec![1, 2, 3];

The interesting part is that push never says "mutable" in your code; you have to know its signature takes &mut self. The compiler is telling you a fact about a function you did not write, which is why the fix is on a different line from the error.

9. E0599: That type has no such method.

error[E0599]: no method named `push` found for type `{integer}` in the current scope
 --> src/main.rs:3:11
  |
3 |     count.push(1);
  |           ^^^^ method not found in `{integer}`

The fix. Use a type that has it, or the right method for this one.

When the type is right but the method is missing, rustc often lists candidates with similar names, and sometimes tells you a trait exists but is not in scope, which is a use statement away, not a redesign.

10. E0601: Every Rust program starts at a function called `main`, and there isn't one.

error[E0601]: `main` function not found in crate `snippet`
 --> src/main.rs:3:2
  |
3 | }
  |  ^ consider adding a `main` function to src/main.rs`

The fix. Rename the function to main.

The compiler is not looking for your code, it is looking for one specific name. Rust has no "top level" that runs. The entry point is a convention with no flexibility, and this is usually the first time a beginner learns the program has a designated front door.

11. E0618: You put call parentheses after something that is not a function.

error[E0618]: expected function, found `{integer}`
 --> src/main.rs:3:18
  |
2 |     let total = 5;
  |         ----- `total` has type `{integer}`
3 |     let result = total();
  |                  ^^^^^--
  |                  |
  |                  call expression requires function

The fix. Drop the parentheses, or call the function you meant.

Usually a shadowed name: a variable and a function with the same identifier, and the variable won. The help: line will tell you what the thing actually is, which is faster than re-reading your own code.

12. E0765: A string was opened with a quote and never closed.

error[E0765]: unterminated double quote string
 --> src/main.rs:3:25
  |
3 |       println!("{greeting}");
  |  _________________________^
4 | | }
  | |_^

The fix. Close the quote: let greeting = "hello";

Notice the error points at where the string started, not where the compiler gave up. That is the general pattern for unclosed things: the reported line is the opening, because the compiler cannot know which of the following lines you meant to close it on.

13. E0004: A `match` has to cover every possible case and yours misses one.

error[E0004]: non-exhaustive patterns: `Direction::South` not covered
  --> src/main.rs:8:11
   |
 8 |     match d {
   |           ^ pattern `Direction::South` not covered
   |
note: `Direction` defined here
  --> src/main.rs:1:6
   |
 1 | enum Direction {
   |      ^^^^^^^^^
 2 |     North,
 3 |     South,
   |     ----- not covered
   = note: the matched value is of type `Direction`
help: ensure that all possible cases are being handled by adding a match arm with a wildcard pattern or an explicit pattern as shown
   |
 9 ~         Direction::North => println!("up"),
10 ~         Direction::South => todo!(),
   |

The fix. Add the missing arm, or a _ => {} catch-all.

This is the feature you will miss most in other languages. Add a variant to the enum a year later and every match that forgot to handle it fails to compile. The compiler maintains your switch statements for you.

14. E0005: That pattern can fail, and `let` has nowhere to go when it does.

error[E0005]: refutable pattern in local binding
 --> src/main.rs:3:9
  |
3 |     let Some(value) = maybe;
  |         ^^^^^^^^^^^ pattern `None` not covered
  |
  = note: `let` bindings require an "irrefutable pattern", like a `struct` or an `enum` with only one variant
  = note: for more information, visit https://doc.rust-lang.org/book/ch19-02-refutability.html
  = note: the matched value is of type `Option<i32>`
help: you might want to use `let...else` to handle the variant that isn't matched
  |
3 |     let Some(value) = maybe else { todo!() };
  |                             ++++++++++++++++

The fix. Use if let Some(value) = maybe { … } or let Some(value) = maybe else { … };

let must always succeed, so it only accepts patterns that cannot fail. This is where if let and let … else come from: they are the versions with somewhere to put the failure.

15. E0063: You built a struct without all of its fields.

error[E0063]: missing field `y` in initializer of `Point`
 --> src/main.rs:7:13
  |
7 |     let p = Point { x: 1 };
  |             ^^^^^ missing `y`

The fix. Supply y too.

There is no partially-built struct in Rust. Every field is set at construction or the value does not exist, which is why you never have to check whether a field was initialised.

16. E0070: The left side of `=` has to be something that can be assigned to.

error[E0070]: invalid left-hand side of assignment
 --> src/main.rs:2:7
  |
2 |     5 = 6;
  |     - ^
  |     |
  |     cannot assign to this expression

The fix. Assign to a variable, or use == if you meant to compare.

Almost always a == typed as =. In C this class of typo silently compiles inside an if; Rust rejects it because a condition must be a bool and an assignment is not one.

17. E0382: The value moved to a new owner, and you used the old name afterwards.

error[E0382]: borrow of moved value: `name`
 --> src/main.rs:4:16
  |
2 |     let name = String::from("crab");
  |         ---- move occurs because `name` has type `String`, which does not implement the `Copy` trait
3 |     let other = name;
  |                 ---- value moved here
4 |     println!("{name}");
  |                ^^^^ value borrowed here after move
  |
help: consider cloning the value if the performance cost is acceptable
  |
3 |     let other = name.clone();
  |                     ++++++++

The fix. Clone it, or borrow with &name, or use other.

Read the note: rather than the error: move occurs because String does not implement the Copy trait. That single line is the whole ownership model. An i32 in the same code would have been fine, because copying eight bytes is free and copying a heap allocation is not.

18. E0423: You used a struct's name where a value was expected.

error[E0423]: expected value, found struct `Config`
 --> src/main.rs:6:13
  |
1 | / struct Config {
2 | |     debug: bool,
3 | | }
  | |_- `Config` defined here
...
6 |       let c = Config;
  |               ^^^^^^ help: use struct literal syntax instead: `Config { debug: val }`

The fix. Construct it: Config { debug: true }.

A struct name is a type, not a value, unless it is a unit struct, in which case the name is the value. That inconsistency is real and worth knowing, and the error message tells you which case you are in.

19. E0428: Two things with the same name in the same scope.

error[E0428]: the name `total` is defined multiple times
 --> src/main.rs:5:1
  |
1 | fn total() -> i32 {
  | ----------------- previous definition of the value `total` here
...
5 | fn total() -> i32 {
  | ^^^^^^^^^^^^^^^^^ `total` redefined here
  |
  = note: `total` must be defined only once in the value namespace of this module

The fix. Rename one of them.

No overloading in Rust: one name, one item, per scope. This is the language deciding that "which one did I call?" should never be a question you have to answer.

20. E0432: The path in your `use` statement does not exist.

error[E0432]: unresolved import `std::collections::HashMapp`
 --> src/main.rs:1:5
  |
1 | use std::collections::HashMapp;
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^ no `HashMapp` in `collections`
  |
help: a similar name exists in the module
  |
1 - use std::collections::HashMapp;
1 + use std::collections::HashMap;
  |

The fix. Fix the spelling: HashMap.

Import errors surface before type errors, so a single typo in a use line can produce a cascade of unrelated-looking failures below it. Always fix the topmost error first and recompile. Most of the rest often vanish.

21. E0433: The type exists in the standard library but has not been brought into scope.

error[E0433]: cannot find type `HashMap` in this scope
 --> src/main.rs:2:18
  |
2 |     let scores = HashMap::new();
  |                  ^^^^^^^ use of undeclared type `HashMap`
  |
help: consider importing this struct
  |
1 + use std::collections::HashMap;
  |

The fix. use std::collections::HashMap;

Rust's prelude is deliberately tiny: only the handful of items nearly every program needs. Everything else you import by hand, and rustc will usually print the exact use line, which you can paste.

22. E0609: That struct has no field by that name.

error[E0609]: no field `z` on type `Point`
 --> src/main.rs:8:22
  |
8 |     println!("{}", p.z);
  |                      ^ unknown field
  |
help: a field with a similar name exists
  |
8 -     println!("{}", p.z);
8 +     println!("{}", p.x);
  |

The fix. Use a field that exists, or add it to the struct.

rustc lists the fields that do exist, which makes this one of the errors you can fix without leaving the terminal. Worth noticing: the available-fields list is the compiler volunteering information you did not ask for.

The pattern behind all of them

Once you've read a few hundred of these, they stop being 22 separate errors and become four questions:

Who owns this value, and did I give it away? Ownership errors.
How long does this reference need to live? Lifetime errors.
Does this type do the thing I'm asking of it? Trait errors.
Did I say what I meant? Type, scope and mutability errors.

That's the language's whole difficulty curve, and the compiler tells you which of the four you're in every single time.

If you want to practise these against a real compiler without installing anything, that's what I built codecrab for: actual rustc output, the failing span underlined in your own source, one hint at a time. 94 exercises. Exercises derive from rustlings (MIT).

Compiling costs real money and I'd like this to still exist in 2028. The 94 exercises above stay free - the Pro subscription Pass raises the daily compile limit and opens the courses built from the error corpus.

https://codecrab.app/

Forward Deployed Engineer is outsourcing with a better logo

Mykhailo — Fri, 14 Aug 2026 00:26:41 +0000

I spent more than five years in outsourcing companies. That is where I started my career.

The job looked like this: get assigned to a client, learn their infrastructure, fight their legacy systems, sit in calls with people who could not describe what they wanted, ship something that worked, move to the next client. Sometimes I was on their VPN more than my own employer's. Sometimes I knew their systems better than their own staff did.

Now the same job has a new name and a salary that can be twice as high. It is called Forward Deployed Engineer.

Where the name came from

The term belongs to Palantir. The earliest published use I could find is a TechCrunch piece from June 2010 about a funding round, which identifies one of their employees by the title forward deployed engineer.

The name is borrowed from the military, where a forward deployed unit sits in the field instead of at home base. That is the whole idea. Palantir was selling data integration software to intelligence and defense customers who could not describe what they needed, partly because the requirements were classified and partly because nobody had written them down. Shipping the software did not work. So they shipped engineers, cleared and embedded on site, writing production code inside the customer's environment for months at a time.

Internally Palantir called them Deltas, a name they explain in their own post on Dev versus Delta. According to The Pragmatic Engineer, the company had more FDEs than regular software engineers until roughly 2016. That is a striking ratio for a company that sells a product. There is also a day in the life of an FDE from 2022 if you want their version of the job.

So the name is about fifteen years old, and the current wave of AI companies hiring FDEs did not invent anything. They picked up a label that already had a decade of history and a good story attached to it.

The job description is identical

Read what an FDE is supposed to do. Integrate a vendor's product with the client's messy data. Build custom pipelines and workflows on top of it. Sit with non-technical stakeholders and translate business pain into technical requirements. Feed real-world edge cases back to the product team.

Now read what I did in outsourcing. Integrate whatever the client bought with whatever the client already had. Build custom pipelines on top of it. Sit with non-technical stakeholders and translate business pain into technical requirements. File bugs and feature requests upstream when the vendor's product could not do the thing the client paid for.

I cannot find the daily difference. Same messy enterprise APIs. Same undocumented internal system that one person understands and that person is on vacation. Same client stakeholder who changes the requirement after the sprint started. Same travel, same context switching, same burnout curve.

What actually differs

Two business models, one job description.

An outsourcing agency sells hours. The unit of revenue is a person occupying a seat for a month. If a client cuts ten engineers, the agency loses ten engineers of revenue. Every engineer is a line item, and line items get negotiated down. That is why the rate is what it is, and it is why the agency's incentive is to keep bodies billable rather than to make any single engineer irreplaceable.

A product vendor sells licenses. The unit of revenue is an annual contract with a margin an agency will never see. The engineer they send into the client is not the product. The engineer is what makes the contract renew. One person who unblocks a stuck rollout can be the reason a seven-figure renewal happens instead of a churn. That is a very different number to justify a salary against.

If you want the numbers, levels.fyi has them. Palantir's forward deployed software engineer sits around $211K median. An EPAM engineer in the US is $165K. Accenture is closer to $109K. The frontier labs pay far more than any of them, but they pay everyone far more, so that gap is the company and not the title.

The lock-in argument does not hold up

The usual defense is that outsourcing and FDE work create different kinds of dependency. Outsourcing locks the client into people who understand the custom code. FDE work locks the client into the vendor's platform.

Both are lock-in. I have watched both happen. I have written the pipeline that nobody else could maintain, and I have also been the one who inherited someone else's version of it three years later and needed two weeks just to draw the diagram.

The distinction people draw is real but small. It describes who captures the value, not what the engineer does with their day. An engineer wiring a client's legacy database into a vendor's domain model is doing the same work whether the invoice says time and materials or annual license.

What I would actually tell someone trying to make the jump

If you are in outsourcing and you want the FDE title and the FDE compensation, the honest advice is to stop optimizing your engineering and start optimizing three other things.

Learn one product deeply instead of ten stacks shallowly. Outsourcing rewards breadth. You get thrown at whatever the next contract needs, and after five years you have touched a dozen stacks and mastered none of them. Product companies hire for the opposite. They want someone who knows their platform's data model well enough to argue with the core team about it. Pick a platform, go deep, get certified if the vendor offers it, build something real on it in public.

Get comfortable being wrong in front of executives. In outsourcing my escalation path was almost always internal. There was an account manager and a delivery lead between me and anyone who owned a budget. FDE work removes those layers. You are in the room where the customer decides whether to keep paying, and you have to say "that integration will take three weeks and here is why" to someone who wanted to hear one week.

Go find out what they are actually hiring for. Change your LinkedIn title to Forward Deployed Engineer and start reading the job posts. Scrape them if you want, there is nothing hidden here. A few dozen descriptions will tell you what the requirements really are, and once you line them up against your own CV the gaps are obvious. Then build a plan to close them.

What you will notice is that almost every one of these roles is at a product company. So you need a product mindset. Not just "solve the client's problem", but understand why the company put you at this particular client, what that account means to them, and what happens if it goes badly.

None of this is about writing better code. If you are already the person the client asks for by name, you have the engineering part.

The part I am not sure about

I do not know how durable the FDE label is. Roles that exist to make a specific product land tend to get squeezed when the product gets easier to deploy, or when the vendor decides the work belongs to a partner network. That is more or less what happened to a lot of specialist consulting niches over the last decade.

I also do not know whether the pay gap survives the title becoming common. Right now it is scarce enough that the compensation reflects the revenue it protects. In five years there may be a lot of people with FDE on their profile, and the salary may look a lot more like a senior engineer's, and the same people who chased the title will be looking for the next one.

I did this job for five years before it had the good name. Nobody called it strategic then, and I still cannot tell whether they were wrong about the work or just early on the pricing.

Originally published on yetmike.com.

Podman Lost to Docker. I Stopped Fighting It.

Mykhailo — Mon, 27 Apr 2026 20:18:32 +0000

Most "Podman vs Docker" articles treat it as a technical comparison. It isn't. It's a migration cost problem.

The technical case for Podman is real: rootless by default (not opt-in like Docker's 20.10 mode), no dockerd running as root, no $9–15/user/month for Docker Desktop, and Quadlet (5.0, 2025) for native systemd integration. These are genuine architectural wins.

But Stack Overflow's 2025 survey shows Docker at 71.1% adoption — the largest single-year jump of any technology. Podman at 11.1%. Docker Hub: 318 billion pulls. Podman Desktop: 3 million total downloads since launch.

That's not a competitor. That's a niche.

The question that actually matters

Not "which is better?" but "what context are you in?"

Starting fresh — use Podman if it fits. On RHEL, it's the obvious choice: Red Hat ships it by default, Quadlet integrates directly with systemd, rootless-by-default matters when someone audits your runtime. The CNCF accepted it into sandbox in January 2025. Greenfield project, no legacy tooling — go for it.

Migrating an existing Docker setup — think twice. This is where the calculation breaks down. The spreadsheet shows Docker Desktop at $9–15/user/month. It doesn't show:

Migration day
Debugging socket path differences (Podman uses a different socket location than Docker)
Updating CI pipelines built around Docker socket compatibility
Fixing Dev Containers when VS Code stops finding the right runtime
The 30-minute Podman explanation for every new hire who's never heard of it

These are real hours from real people. None of them ship anything a user will ever see.

Why Docker won anyway

Not on merit. On surface area.

GitHub Actions assumes Docker. Rancher Desktop defaults to Docker. MCP server configs reference Docker. Every Stack Overflow answer assumes Docker. Every internal platform template your company has written assumes Docker.

When you switch, you're not just swapping a binary. You're swimming against the accumulated inertia of every tool your team uses daily. Podman's remaining real advantages — daemonless architecture, rootless-by-default, Quadlet — are genuinely better. They're also genuinely invisible to 90% of the people making the decision.

I wrote about the full trade-off breakdown, including where each argument actually landed and what Docker did and didn't fix, in the original post on yetmike.com.

The short version: run the numbers with migration costs included. Then decide.

Originally published on yetmike.com

DEV Community: Mykhailo

Cilium Certified Associate: I Scored 82, and eBPF Was Only 10% of It

Study to the weights

Identity, not IP

L7 policy needs Envoy

Service Mesh is where I lost points

Hubble and kube-proxy replacement

Two weeks of prep

Result

Passing the OTCA With 83: Half the Exam Is the SDK Pipeline

Format and weights

Don't study backends

The SDK domain

Context propagation

The Collector is a full pipeline

What worked and what didn't

Where my 83 came from

Prometheus Certified Associate: How PromQL Decides Whether You Pass

Format and domains

PromQL

Fundamentals

Metric types

Alerting

How I prepared

Thinking in label sets

Kyverno Certified Associate (KCA): where I lost points and how I'd prepare

No Rego, no DSL

Format and domains

Policy types (and the bit I'm unsure about)

Admission controller vs policy controller

The CLI is the cheapest 12%

Where I lost points

How I'd prepare

Two questions for every answer

Certified Backstage Associate: I Passed by Five Points

Why CNCF exam habits don't help

Customizing Backstage (32%)

Development Workflow (24%)

Infrastructure (22%)

Catalog (22%)

How I prepared, and what I'd change

Three cargo errors that don't happen any more

A manifest with no version

A misspelled key in [profile.release]

A virtual manifest with one member

Why I'd have got all three wrong

CAPA Exam Guide: Argo CD Is Only a Third of It. I Scored 93

Format and weights

Workflows (36%)

Argo CD (34%)

Rollouts (18%)

Events (12%)

How I prepared

Practice test

Every rustc error has two spans, and they mean different things

The same shape, one step harder

And once more, with three

Why I think this matters more than the error codes

CGOA exam prep: why 50 clusters of Argo CD got me an 82

Format

30% of the exam is four sentences

Terminology cost me the most

Pull vs push, and related practices

How I'd prepare

The mental model

The 22 Rust errors every beginner hits, in the order they hit them

1. E0061: The function takes two arguments and you passed one.

2. E0277: Vec has no single obvious way to print itself, so {} will not take it.

3. E0282: Rust cannot work out what type this collection holds, because nothing was ever put in it.

4. E0308: You promised an i32 and returned nothing.

5. E0381: The variable was declared but never given a value, and you read it.

6. E0384: let bindings do not change unless you say mut.

7. E0425: You used a name that was never declared in this scope.

8. E0596: You called a method that needs to modify the value, on a binding that cannot be modified.

9. E0599: That type has no such method.

10. E0601: Every Rust program starts at a function called main, and there isn't one.

11. E0618: You put call parentheses after something that is not a function.

12. E0765: A string was opened with a quote and never closed.

13. E0004: A match has to cover every possible case and yours misses one.

14. E0005: That pattern can fail, and let has nowhere to go when it does.

2. E0277: `Vec` has no single obvious way to print itself, so `{}` will not take it.

4. E0308: You promised an `i32` and returned nothing.

6. E0384: `let` bindings do not change unless you say `mut`.

10. E0601: Every Rust program starts at a function called `main`, and there isn't one.

13. E0004: A `match` has to cover every possible case and yours misses one.

14. E0005: That pattern can fail, and `let` has nowhere to go when it does.

16. E0070: The left side of `=` has to be something that can be assigned to.

20. E0432: The path in your `use` statement does not exist.