DEV Community: LearnSome.tech

What the new Security+ (SY0-801) exam actually is, and what it doesn't prove

Ayodele — Thu, 05 Nov 2026 15:24:35 +0000

AI-assisted: written with an AI tool from CompTIA's own Security+ V8 page, then checked line by line against it. I run LearnSome.tech, which has a Security+ course; this post stands on its own.

CompTIA's Security+ V8, exam code SY0-801, has a launch date of 17 November 2026 on CompTIA's exam page. If you are deciding whether to sit it, here is what it is, from that page rather than from forum lore.

The format

As listed on CompTIA's V8 exam page:

Questions: a maximum of 90, a mix of multiple-choice and performance-based questions (PBQs).
Time: 90 minutes.
Passing score: 750 on a scale of 100 to 900.
Recommended experience: a security administrator with two years of hands-on experience. That's a recommendation, not an entry requirement.
Lifetime: CompTIA estimates the version will retire about 3 years after launch.

PBQs are the part people underestimate. Instead of picking a letter, you classify, order or configure things in a small simulated environment. They take longer than a multiple-choice question, so plan your time around them rather than discovering them at minute 70.

The five domains

The weights, from CompTIA's published V8 objectives summary:

Domain	Weight
Security Operations	27%
Threats, Vulnerabilities, and Attacks	24%
Security Architecture	19%
General Security Concepts	16%
Security Program Management and Oversight	14%

Two things stand out in V8. Security Operations is the largest domain: monitoring, identity and access, incident response, investigations. And the threats domain now has an objective on the security risks of AI systems: models, prompts, privacy and data exposure.

Read the qualifier word

Many Security+ questions offer several answers that are all good security. One word decides which one scores: BEST, FIRST, MOST, LEAST or NOT.

Try this one, in that style:

A user reports they approved an MFA prompt they did not start. What should you do FIRST?

A. Revoke the user's sessions and reset the password
B. Check the mail gateway for the phish
C. Send an awareness reminder to all staff
D. Disable MFA for the user

Every option except one is something a team might do at some point. The question only asks about the first move. Read the qualifier, then the options, and you'll stop losing marks to answers that are right but not first.

What a pass does and doesn't show

A pass shows you know core security practice across those five domains, and the PBQs show you can apply some of it in a simulation. It doesn't replace security work on real systems: nobody's first incident looks like an exam item.

Before you book

Download CompTIA's full V8 objectives and mark each one you couldn't explain to a colleague. That list is your study plan.
Practise PBQ-style tasks (ordering, matching, filling in tables), not just question banks.
Do a timed run of 90 questions in 90 minutes at least once. A minute a question goes fast.

Are you sitting V8, or did you take V7 before the switch?

Terraform Associate (004): what the exam is, and the one thing it can't check

Ayodele — Thu, 05 Nov 2026 15:24:27 +0000

AI-assisted: I put this together from HashiCorp's Terraform Associate (004) page with help from an AI tool, and checked each fact against that page. I run LearnSome.tech, which teaches Terraform; you can prepare without us.

The Terraform Associate is HashiCorp's foundational Terraform certification. The current version is 004. Here is what the official page says, and what it leaves out.

The facts

Format: multiple choice, online proctored.
Duration: 1 hour.
Terraform version tested: 1.12.
Price: USD 70.50 plus local taxes and fees. A free retake is not included.
Valid for: 2 years.
Prerequisites: basic terminal skills and an understanding of on-premises and cloud architecture. HashiCorp says professional experience is recommended, but you can also prepare by practising the objectives in a personal demo setup.

What the page doesn't publish: the number of questions, the pass mark, or any weighting between the objective areas. So you can't game it by skipping a "small" domain. Every area can matter.

The eight objective areas

Infrastructure as Code with Terraform
Terraform fundamentals (providers, and how Terraform uses state)
The core workflow: init, validate, plan, apply, destroy, fmt
Terraform configuration: resources and data blocks, variables and outputs, complex types, expressions and functions, dependencies, custom conditions, sensitive data
Modules: sources, variable scope, versions
State management: the local backend, locking, remote state, drift
Maintaining infrastructure: import, inspecting state from the CLI, verbose logging
HCP Terraform: workspaces and projects, collaboration and governance

How I'd study for a one-hour, unweighted exam

Do the workflow with your hands, even though the exam won't ask you to. Questions about plan and apply are far easier when you have watched a plan want to replace something you didn't expect. A free local setup is enough: a local_file or a random provider resource lets you practise state, import and drift with no cloud bill.

Know the state questions cold. State, backends and locking appear in two separate areas (2 and 6). Be clear that not every backend locks, that a backend block takes literal values only, and that marking a value sensitive hides it from output but not from the state file.

Read the HCP Terraform area properly. It's a whole objective area, and people who only use the CLI tend to skim it.

The thing it can't check

Multiple choice shows you know Terraform's workflow and language. It doesn't test hands-on skill, and it doesn't replace managing real infrastructure: reading a plan carefully before you approve it is a habit, and no exam can see habits.

What's the Terraform concept that took you longest to really get?

AWS Solutions Architect Associate (SAA-C03): the exam in plain numbers, and how its questions are built

Ayodele — Thu, 05 Nov 2026 15:24:18 +0000

AI-assisted: compiled with an AI tool from AWS's exam page and the SAA-C03 exam guide, and checked against both. I run LearnSome.tech, which has an AWS Solutions Architect course; the advice here doesn't need it.

The AWS Certified Solutions Architect – Associate is often the first "real" AWS certification people sit. Here is the exam as AWS describes it, and the question pattern that trips up people who know the services well.

The numbers

Questions: 65, each multiple choice (one right answer) or multiple response (two or more).
Scored: 50 of the 65. The other 15 are unscored pretest questions, and you can't tell which are which.
Time: 130 minutes, so two minutes a question.
Pass mark: 720 on a scaled score of 100 to 1,000.
Cost: USD 150.
Valid for: 3 years.
Recommended: at least 1 year of hands-on experience designing cloud solutions on AWS. AWS also suggests the Cloud Practitioner first for people with no IT experience.

The four domains

Domain	Weight
Design Secure Architectures	30%
Design Resilient Architectures	26%
Design High-Performing Architectures	24%
Design Cost-Optimized Architectures	20%

Security is the biggest single domain, which surprises people who expect an architecture exam to be mostly about compute and storage.

How the questions are built

Most questions describe a requirement and then add a qualifier: least operational overhead, most cost-effective, highest availability. Often every option would technically work. The qualifier decides which one scores.

Here's one in that shape:

An orders database must fail over to another Availability Zone automatically, with no change to the address the application connects to, and with the least operational overhead. What should the team do?

A. Convert the database to a Multi-AZ deployment
B. Create a read replica in another zone and write a script that promotes it on failure
C. Take a snapshot every hour and restore the latest one in another zone after a failure
D. Move the database to a larger instance

Before you pick, underline the three requirements: automatic, same address, least overhead. Then strike out each option that misses any one of them. That habit, more than memorising service limits, is what the exam rewards.

Two pacing habits worth practising

Flag and move. Two minutes a question is tight. When one runs long, choose your best option, flag it, and come back on a second pass with the time you saved.
Answer everything. An unanswered question is simply wrong, so never leave one blank at the end.

What it proves

Passing shows you can choose sound AWS designs from a description. It doesn't test hands-on skill, and it doesn't replace building on AWS: the console, the bill and the 2 a.m. alarm teach things a multiple-choice exam can't.

Which domain did you find hardest?

Linux permissions beyond rwx: umask, the sticky bit, setuid and hard links

Ayodele — Thu, 05 Nov 2026 15:24:12 +0000

This is AI-assisted: I built it from our Linux glossary entries with an AI tool's help and checked the behaviour against the man pages. I run LearnSome.tech, where the glossary lives; nothing below needs an account anywhere.

Everyone learns rwx and chmod 644 early. Then something odd happens: a new file comes out with permissions nobody set, or you can write to a directory but can't delete a file in it. These four words explain most of it.

umask: where default permissions come from

New files start from 666 and new directories from 777, and the umask removes bits from both. With the common umask 022, files come out 644 and directories 755. With 077, nobody but you gets any access.

umask          # show the current mask, e.g. 0022
umask 077      # this shell and the programs it starts: private by default
touch secret.txt && ls -l secret.txt   # -rw-------

The umask is inherited by child processes, so a service started with a loose umask writes loose files.

The sticky bit: why you can't delete someone else's file in /tmp

/tmp is writable by everyone, yet you can't remove another user's file in it. That's the sticky bit: on a directory, it lets users delete or rename only their own files.

ls -ld /tmp    # drwxrwxrwt: the trailing t is the sticky bit
chmod 1777 shared/   # the leading 1 sets it in octal

It adds a rule about removing names. It doesn't replace the normal read, write and search permissions.

setuid: running as the file's owner

A setuid executable runs with its owner's identity, not the identity of whoever started it. That's how passwd, owned by root, can update a file an ordinary user can't touch.

It also means every setuid-root program is part of your security perimeter: a flaw in one can hand an attacker root. Keep them few, owned by root, not writable by anyone else, and know which ones you have:

find / -xdev -perm -4000 -type f 2>/dev/null   # list setuid files on this filesystem

Hard links: one file, two equal names

A file's data and metadata live in an inode; a name in a directory just points at it. A hard link is a second name for the same inode. Neither name is the "original": edit through one and the other sees it, because there's only one file.

ln report.txt report-copy.txt
ls -li report*.txt   # same inode number, link count 2

That explains a classic surprise: deleting a name doesn't free the space while another hard link still points at the inode. It also explains why a filesystem can run out of inodes while it still has free space.

The one-line takeaway

When permissions surprise you, check four things: the umask that created the file, any special bits on the directory, any special bits on the program, and how many names point at the inode (ls -li).

Which of these surprised you most when you first ran into it?

Write a one-page responsibility map for every cloud service you run

Ayodele — Thu, 05 Nov 2026 15:24:07 +0000

AI-assisted: written with an AI tool and checked against the AWS, Microsoft Azure and Google Cloud pages on shared responsibility. I run LearnSome.tech, which teaches cloud certifications; this exercise needs nothing from it.

Everyone can recite "the provider secures the cloud, you secure what's in it". The trouble starts when a real service lands on your bill and nobody can say who patches what. So here is the model as an exercise you can finish in an afternoon.

The one rule that never moves

Whatever the service, your data and your identities are yours. Classifying and protecting the data, deciding who has an account, enforcing MFA, removing leavers: no provider does those for you, in IaaS, PaaS or SaaS.

Everything else moves depending on the kind of service:

Layer	IaaS (a VM)	PaaS (a managed platform)	SaaS (an application)
Your data	You	You	You
Accounts and access	You	You	You
Applications	You	Shared	Shared
Network controls	You	Shared	Provider
Operating system	You	Provider	Provider
Hosts, hypervisor, data centre	Provider	Provider	Provider

That table follows Microsoft's breakdown; AWS and Google describe the same split in their own words.

The exercise

For each service on your bill, write four lines:

service: Amazon EC2 (orders web server)
patches the OS: us (the guest OS is ours on EC2)
network rules: us (security groups, VPC)
holds the keys: us (SSH keys, IAM roles)
leads an incident: us, with AWS for anything below the hypervisor

service: managed database (orders DB)
patches the OS: provider
network rules: shared (we decide what may connect; security groups again)
holds the keys: us (database users, encryption key choices)
leads an incident: depends: write down which cases are ours

service: email and documents suite (SaaS)
patches the OS: provider
network rules: provider
holds the keys: us (accounts, MFA, sharing settings)
leads an incident: us, for anything an account or a share setting caused

Any line you can't fill in from the provider's own documentation is a question for your team, not a gap to leave blank.

Three mistakes the map catches

"Managed" read as "secured for you". Even in PaaS and SaaS, application configuration, code security and access controls stay with you.
One split for everything. Your share changes per service. EC2 and a managed database sit on very different rows.
Incidents left to the provider. Incident handling is often the least clearly divided area. Many incidents start with a misconfigured resource or stolen credentials, and both of those are on your side.

The map is also a good onboarding document: a new engineer reads it and knows which alerts are theirs.

What's the service where your team disagreed most about who owns what?

Four Git words that get your work back: reflog, detached HEAD, stash and the index

Ayodele — Thu, 05 Nov 2026 15:24:03 +0000

AI-assisted: these definitions come from the Git glossary we keep at LearnSome.tech, turned into a post with help from an AI tool and checked against the Git documentation. I run LearnSome.tech; you don't need it to use any of this.

If you committed it, it's very likely still there, even after a bad reset or rebase; you just need the words to find it. (Changes you never committed or stashed are another story, which is why the last section matters.) Here are four words worth knowing.

1. The reflog

What it is: Git's local record of every position HEAD and each branch has pointed at.

Every commit, checkout, reset, rebase and merge adds an entry such as HEAD@{2}. So after a bad reset --hard or a rebase that went wrong, the old commit is usually one command away:

git reflog                        # find the line from before the mistake
git branch rescued <commit-id>    # put a branch on it so it can't get lost

Know its limits: it lives only in your clone (a teammate's reflog won't help you), and entries expire, by default after about 90 days, or 30 for commits nothing points at any more.

2. Detached HEAD

What it is: HEAD holding a commit ID directly instead of a branch name.

You get there by checking out a commit, a tag or a remote-tracking branch. It's a normal state for looking around, not an error. The catch: if you make commits while detached, no branch moves to follow them, and Git warns you when you leave because they'll only survive while something points at them.

git switch -c keep-this-work      # before or after leaving: give the commits a branch

3. git stash

What it is: a command that saves your uncommitted changes aside and returns the working tree to the last commit.

git stash          # staged and unstaged changes to tracked files
git stash list     # what's saved
git stash pop      # reapply the newest entry and drop it from the list

The gotcha: untracked files stay where they are unless you add -u. People stash, switch branch, and then wonder why a new file followed them.

4. The staging area (the index)

What it is: Git's list of exactly what the next commit will contain, kept in .git/index.

It holds a complete tree, not just a list of changed names. git add copies a file into it as it is at that moment, so if you edit the file again after adding it, the staged copy stays as it was. That's why git status can show the same file as both "staged" and "modified".

git diff            # working tree vs the index: what you haven't staged
git diff --staged   # the index vs the last commit: what will be committed

The habit that ties them together

Before any command that rewrites history (reset, rebase, commit --amend), run git status and glance at git log --oneline -5. If something goes wrong, you'll recognise the commit you need in the reflog.

Which of these four have you had to look up in a panic?

CKA or CKAD first? Let your ticket queue decide

Ayodele — Thu, 05 Nov 2026 15:23:58 +0000

AI-assisted: I drafted this from the Linux Foundation's exam pages and FAQ and used an AI tool to edit it. I run LearnSome.tech, where we have CKA and CKAD courses; you can make this decision without them.

People ask "which is harder?" The more useful question is "which one looks like my job?" Here is why.

The format is the same

Both are online, proctored, performance-based exams: around 15 to 20 tasks solved on the command line, on Linux hosts with kubectl already set up (with the k alias and Bash completion). Both give you 2 hours, both need 66% to pass, and each costs USD 445 including one free retake. Neither has a prerequisite. Both certifications are valid for 2 years.

So difficulty comes down to which tasks feel further from your day.

The work is different

The CKA is about running the cluster. Its heaviest domain is Troubleshooting at 30%, then Cluster Architecture, Installation and Configuration at 25%: kubeadm, upgrades, RBAC, a highly available control plane.

The CKAD is about the apps on the cluster. Its heaviest domain is Application Environment, Configuration and Security at 25%, with Design and Build, Deployment, and Services and Networking at 20% each: building images, probes, rolling updates, ConfigMaps and Secrets.

A CKA-style task:

# "worker-1 is NotReady. Make it Ready, and keep it Ready after a reboot."
kubectl describe node worker-1          # conditions and taints first
ssh worker-1
sudo journalctl -u kubelet -n 50        # why the kubelet stopped
sudo systemctl enable --now kubelet     # fix it and make it survive a reboot

A CKAD-style task:

# "The web app in namespace shop is Running but gets no traffic. Fix it."
kubectl -n shop get pods,endpointslices # Running pods, empty endpoints
kubectl -n shop describe pod -l app=web # readiness probe on the wrong port
kubectl -n shop edit deployment web     # fix the probe, then verify endpoints

The decision

You mostly ship apps to a cluster someone else runs: CKAD first.
You build images and write manifests: CKAD first.
You upgrade, repair or secure clusters and nodes: CKA first.
The CKS is your goal: CKA first, because the CKS requires a passed CKA.
Not sure: look at the last ten tickets you closed and count which list they fit.

If you plan both

They overlap more than people expect: rolling updates, ConfigMaps and Secrets appear in both curricula. Book the second exam soon after the first, while that shared ground is fresh, and spend the new study time on what the first one didn't cover.

One honest caveat: passing either shows you can do the tasks under time. It doesn't replace running clusters or apps in production.

Which one did you take first, and would you choose the same again?

My Kubernetes Service gets no traffic: the five checks I run, in order

Ayodele — Thu, 05 Nov 2026 15:23:53 +0000

AI-assisted note: I wrote the checks from the ones I actually run, and an AI tool helped with the wording. The behaviour is checked against the Kubernetes documentation on Services. I run LearnSome.tech, where we teach Kubernetes; nothing here depends on it.

Most "my Service is broken" problems aren't about the Service type at all. They are a selector that matches nothing, pods that aren't Ready, or a port that points at the wrong place. But it helps to know what each type promises first.

The types in one table

Type	Who can reach it	Builds on
ClusterIP (the default)	Clients inside the cluster	Nothing, it's the base
NodePort	Anyone who can reach a node, on a port from 30000-32767 by default	ClusterIP
LoadBalancer	Clients of the cloud load balancer	NodePort
ExternalName	Not a proxy: in-cluster clients get a DNS alias to another name	No cluster IP at all

The types nest: a NodePort Service also gets a cluster IP, and a LoadBalancer Service still allocates a node port by default. That last one surprises people when they look at firewall rules:

$ kubectl get svc web
NAME   TYPE           CLUSTER-IP    EXTERNAL-IP    PORT(S)
web    LoadBalancer   10.96.12.40   203.0.113.10   80:31234/TCP

80 is the Service port; 31234 is a node port that is open on every node too. Pick the narrowest type that still reaches your clients.

The five checks

When a Service exists but its pods never see a request, I go through these in order and stop at the first one that fails.

# 1. Does the Service exist, with the type and ports I expect?
kubectl get svc web -o wide

# 2. Did its selector find any pods? An empty endpoint list means no.
kubectl get endpointslices -l kubernetes.io/service-name=web

# 3. Selector vs pod labels, character by character
kubectl get svc web -o jsonpath='{.spec.selector}'; echo
kubectl get pods --show-labels

# 4. Are the pods Ready? Pods that aren't Ready don't get Service traffic.
kubectl get pods -l app=web

# 5. Does targetPort match the port the container listens on?
kubectl get svc web -o jsonpath='{.spec.ports[*].targetPort}'; echo

Step 2 is the one that saves the most time. Kubernetes keeps EndpointSlice objects in step with each Service's selector and with pod readiness, so an empty slice tells you the problem is the selector or readiness, not DNS and not the network.

Step 4 catches a sneaky one: a readiness probe pointed at the wrong port. The pods show Running, nothing restarts, and the Service still has no endpoints, because a failing readiness probe only takes the pod out of rotation.

If all five pass, bypass the Service and call a pod directly. If that fails too, the problem is in the app, not in Kubernetes.

When a Service isn't the answer

If what you need is HTTP routing from outside the cluster (several paths or hostnames behind one entry point), you want an Ingress or a Gateway in front of ClusterIP Services, not a LoadBalancer per app. The Kubernetes project now recommends Gateway over Ingress, whose API is frozen.

Which of the five checks has caught you most often?

Reviewing a multi-stage Dockerfile: six things I check

Ayodele — Thu, 05 Nov 2026 15:23:47 +0000

AI-assisted: the checklist and the example are mine, and an AI tool helped tighten the wording. Every behaviour below is checked against Docker's own documentation on multi-stage builds and build secrets. I run LearnSome.tech, where we teach Docker; you don't need it for anything here.

A multi-stage build is a Dockerfile with more than one FROM. Each FROM starts a new stage from a clean slate, and COPY --from=<stage> carries only the files you name into the next one. The compiler, the test tools and the source stay behind.

Here is the smallest useful shape, a Go program shipped on an empty base:

# syntax=docker/dockerfile:1
FROM golang:1.24 AS build
WORKDIR /src
COPY . .
# a static binary, so it runs on the empty scratch image
RUN CGO_ENABLED=0 go build -o /bin/hello .

FROM scratch
COPY --from=build /bin/hello /bin/hello
CMD ["/bin/hello"]

When I review someone else's multi-stage Dockerfile, these are the six questions I ask.

1. Are the stages named?

FROM golang:1.24 AS build and COPY --from=build keep working when someone reorders the file later. A numbered stage (--from=0) points at whatever stage is first, so adding a stage above it quietly changes what gets copied.

2. What does the last stage actually contain?

Only the last stage ships by default. Check that it starts from a small base and copies in the built output and nothing else: no COPY . . in the final stage. A smaller image means fewer packages, which means fewer vulnerabilities to patch.

3. Can I build one stage on its own?

docker build --target build -t app:build . stops at the stage called build, which is handy for running tests inside it or debugging a failing step. With BuildKit, only the stages the target depends on are built; the legacy builder runs every stage before the target.

4. How does a secret reach the build?

Build arguments and environment variables persist in the final image, so they are the wrong way to hand a build a token. Use a secret mount, which exists only for the one RUN that asks for it:

RUN --mount=type=secret,id=npmtoken \
    NPM_TOKEN=$(cat /run/secrets/npmtoken) npm ci

docker build --secret id=npmtoken,src=./npmtoken .

Copying a secret in and deleting it in a later step doesn't work either: the earlier layer still holds it.

5. Is every `ARG` declared in the stage that uses it?

An ARG declared in one stage isn't visible in an unrelated stage. If two stages need VERSION, both need the ARG VERSION line. This one causes a lot of "why is my variable empty?" questions.

6. Is the base pinned when it needs to be, and is there a `.dockerignore`?

Image tags are mutable, so pin the base to a digest when you need the exact same bytes every time. And a .dockerignore that leaves out .git, local environments and .env files keeps the build context small and stops a broad COPY from picking up something private.

If you only take one thing from this: open your final stage and list every file in it. Anything you can't explain shouldn't be there.

What's the biggest image you've shrunk this way?

Terraform state gotchas I wish someone had told me on day one

Ayodele — Thu, 05 Nov 2026 15:23:38 +0000

AI-assisted: I wrote the outline and the examples, and used an AI tool to tighten the wording. I checked the behaviour below against HashiCorp's documentation. I run LearnSome.tech, where we teach Terraform; this post doesn't need anything from it.

Terraform's state file is easy to ignore until it bites. It's the record that says "this address in my code owns that real thing in the cloud". Lose it or share it carelessly and Terraform's view of the world stops matching reality. These are the gotchas I see most often.

1. Deleting state doesn't delete anything, and that's the problem

Delete terraform.tfstate and your cloud resources are untouched. But Terraform has forgotten they're yours. The next apply plans to create everything again, and you either get duplicates or name clashes.

If you've lost state but the resources exist, don't recreate them. Bring them back under management with terraform import or an import block, then check terraform plan shows no changes.

2. Local state on a team is a race

Two people with their own local state for the same infrastructure will each believe their copy is the truth. The second apply quietly undoes the first.

Do instead: a remote backend everyone shares (HCP Terraform, S3, GCS, azurerm and so on), set up before the second person ever runs Terraform.

3. Assuming locking is on

Locking stops two runs writing state at the same time. Many people assume every backend locks by default. Not all backends support locking, and on S3 it's opt-in:

terraform {
  backend "s3" {
    bucket       = "acme-terraform-state"
    key          = "network/terraform.tfstate"
    region       = "eu-west-2"
    encrypt      = true
    use_lockfile = true   # S3-native locking; the DynamoDB table approach is deprecated
  }
}

Also note that a backend block takes literal values only: no variables or locals.

4. Reaching for force-unlock too quickly

A run says the state is locked. The tempting move is terraform force-unlock <ID>. If the lock belongs to a teammate's apply that's still running, you've just allowed two writers on the same state.

Do instead:

terraform plan -lock-timeout=5m   # wait for a running job to finish

Use force-unlock only for your own lock, when you know the run that held it has died (a crashed CI job, for example), and with the exact lock ID Terraform printed. The command doesn't change infrastructure, but it can let two runs corrupt state.

5. Committing state to Git

It feels like a free backup. It isn't: Git has no locking, everyone's copy diverges, and state contains every attribute Terraform knows about your resources, including secrets (next point). HashiCorp advises against it.

Do instead: a private, versioned bucket (or HCP Terraform). Versioning gives you the history Git would have, without the leaks.

6. Believing `sensitive = true` keeps secrets out of state

sensitive = true hides a value in plan and apply output. It's still in the state file. If you pass a database password into a resource, that password is in state in plain text.

Do instead:

Treat the state file as a secret: encrypted at rest, tight access control, never in Git.
Where your Terraform and provider versions support them, use ephemeral values and write-only arguments, which Terraform leaves out of state and plan files.
Better still, let the cloud generate and store the secret (a secrets manager), and pass Terraform a reference rather than the value.

A quick health check for any Terraform repo

Is there a backend block, and does it lock?
Is *.tfstate in .gitignore, and absent from history?
Who can read the state bucket? Would you be happy if that list could read your production passwords?
Does terraform plan on main show no changes? If not, something changed outside Terraform.

Which of these caught you out first?

Five Kubernetes probe mistakes that turn a slow start into a restart loop

Ayodele — Thu, 05 Nov 2026 15:23:23 +0000

AI-assisted: I wrote the outline and the examples, and used an AI tool to tighten the wording. I checked every behaviour below against the Kubernetes documentation. I run LearnSome.tech, where we teach Kubernetes; this post doesn't need anything from it.

Most probe problems I see aren't exotic. A Pod restarts every few minutes, kubectl get pods shows a climbing RESTARTS count, and the app logs look fine. Nine times out of ten the probes are doing exactly what they were told to do. Here are the five mistakes I look for first.

1. Using liveness to protect a slow start

A JVM service takes 70 seconds to start. Someone adds a liveness probe with the defaults (periodSeconds: 10, failureThreshold: 3, no initial delay), and the kubelet kills the container at about 30 seconds, before it ever listens. It restarts, takes 70 seconds again, and is killed again. After a few rounds you get CrashLoopBackOff, with back-off delays doubling from 10 s up to a 5-minute cap.

Fix: add a startup probe. Until it succeeds, Kubernetes doesn't run liveness or readiness at all. Size it so failureThreshold × periodSeconds covers your worst start, not your average one:

startupProbe:
  httpGet: { path: /healthz, port: http }
  periodSeconds: 10
  failureThreshold: 18   # up to 3 minutes to start

Then liveness can stay strict, because it only begins after the start is done.

2. Checking the database in the liveness probe

If /healthz queries Postgres and Postgres has a bad minute, every replica fails liveness together and Kubernetes restarts all of them. Restarting your app doesn't fix your database; it adds a thundering herd of reconnects on top of the outage.

Fix: liveness answers one question: "is this process stuck?" Keep it in-process and cheap. Put dependency checks in the readiness probe, where a failure only takes the Pod out of the Service's endpoints. Nothing gets killed.

3. Trusting the 1-second timeout

timeoutSeconds defaults to 1. A health endpoint that answers in 40 ms on your laptop can take 1.5 s under load, during a GC pause, or on a noisy node. Three slow answers in a row and the container is restarted, right when it's busiest.

Fix: time the endpoint under realistic load and set timeoutSeconds from that, or make the endpoint cheaper. Health endpoints should return a tiny body; the kubelet stops reading after 10 KiB anyway.

4. Expecting liveness to wait for readiness

It doesn't. Liveness and readiness run independently. A Pod can be "not ready" and still have its liveness probe firing, and failing, the whole time. People add a readiness probe and assume it "protects" the container during warm-up. It doesn't protect it from liveness.

Fix: that's the startup probe's job again (mistake 1), or an initialDelaySeconds on liveness if you really can't add one.

5. Copying the same probe for all three

Same path, same port, same thresholds, pasted three times. It looks tidy, but it erases the difference between "restart me", "don't send me traffic" and "I'm still booting".

Fix: a reasonable starting point:

Startup: the same cheap check as liveness, with a long failureThreshold.
Liveness: cheap, in-process, a few failures before a restart.
Readiness: its own endpoint, may check required dependencies, fails fast (periodSeconds: 5, failureThreshold: 2).

How I debug it

kubectl describe pod <pod>          # Events: "Liveness probe failed: ..." and "Killing"
kubectl get pod <pod> -o jsonpath='{.status.containerStatuses[0].lastState}'
kubectl get endpointslices -l kubernetes.io/service-name=<svc>   # is the Pod in the Service?

If the Events show "Liveness probe failed" just before each restart, it's the probe and not the app. If the Pod is running but gets no traffic, look at readiness and the EndpointSlices.

One habit worth building: before you ship a new liveness probe, run it against a deliberately slow copy of the app. If that copy gets restarted, so will production on a bad day.

What's the strangest probe failure you've had to debug?