When you genuinely have a secret and your whole workflow is git, where does it live? Not plaintext in the repo, not a gitignored file passed around Slack. SOPS with age encrypts the values, commits the ciphertext, keeps git diffs readable, and decrypts only at the point of use. age gives modern key management without the PGP misery; SOPS gives the value-only, multi-recipient, git-friendly workflow. A team's access model becomes a reviewable list of public keys. Plus when SOPS beats Vault and the one thing you must not get wrong.
Two questions get tangled in infrastructure-as-code, and only one is hard. Which tool, Terraform or OpenTofu, is easy - for new work in 2026 use OpenTofu, open-source license, community governance, drop-in compatibility, and move on. The hard part, identical for both because they share a design, is state - the memory that makes declarative infra work and the most dangerous file you own. Here is what state is, the three ways it bites (wrong place, concurrent writes, drift), and why it holds your secrets in the clear.
Part three of the NetBird series. A fresh mesh is flat - every peer reaches every other peer on every port, which is wrong to depend on. Access policies fix it, and the model is RBAC for your network - deny by default once you delete the starter policy, allow-only rules, groups as the unit of access with users as source and infrastructure as destination, and setup keys that auto-assign groups. Plus the two sharp edges (same-group peers always reach each other; subnet routes can bypass access control) and posture checks for real zero trust.
The most dangerous thing in most Azure setups is a stored secret - it leaks, nobody rotates it, and an attacker finds it months later. Managed identities delete it, because the identity becomes the credential and your code gets short-lived tokens by proving what it is. Inside Azure that is one toggle and a scoped role; across the boundary, Workload Identity Federation lets GitHub Actions and Kubernetes authenticate to Azure over OIDC with no stored secret at all. Here is how both work, and the caveats that replace secret rotation.
A nightly pg_dump at 4am means that when prod dies at 3pm you lose eleven hours of data, and there is nothing you can do about it. Postgres already writes down every change as it happens in the WAL. Archive that continuously on top of a base backup and you can recover to any second, including the moment right before someone ran the bad command. That is PITR, and it is the difference between an outage and a catastrophe. With the two numbers, RPO and RTO, that should drive the whole decision.
Around 60% of breaches exploit a vulnerability that already had a patch. The gap is not knowledge, it is deployment, and it stays open because patching genuinely breaks things, there are too many patches, CVSS points at the wrong ones, and nobody owns the forgotten systems. The way through: prioritize by what is actually being exploited (the CISA KEV catalog, not raw severity), tier your response by exposure, automate the boring low-risk majority, and know what you run, because you cannot patch what you forgot you own.
When someone deletes production, the room asks who did it. That is the wrong question. If one person at one terminal with one wrong command can destroy prod, the system that granted that power with no guardrail is the failure, not the human, who is only the last link in a chain of missing controls. Here is why human error is a symptom not a cause, the controls that actually prevent it (least privilege, deletion protection, two-step destructive ops, environment isolation, separate-account immutable backups), and using chaos engineering to test the guardrails before reality does.
It's always DNS stays true because DNS underlies every connection, fails as some other layer's error, and returns wrong answers without ever reporting one. The confusion is almost always caching: many independent caches, each with its own TTL, expiring on its own clock.
kube-bench runs the CIS Kubernetes Benchmark against your cluster and tells you, check by check, where the configuration falls short of the hardening baseline. It is one job to run, it is free, and every cluster should be scored by it at least once. It also has a clear limit worth understanding before you trust a green result.