Start with the Certificate resource in the post, because it is the one place where the comment and the field disagree. It sets `duration: 2160h` and `renewBefore: 720h`, under a comment reading "90-day validity, auto-renewed at 60 days remaining" [11]. 2160 hours is 90 days and 720 hours is 30 days, so cert-manager renews when 30 days remain, on day 60 of the certificate's life [13]. The controller reads the field, not the comment. Copy the block expecting a month of slack after your first failed ACME challenge and you have it; expect two, and you do not.
The ingress fix is small and it is real. `nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"` tells the controller to speak TLS to the backend instead of plain HTTP [7], which is what the post calls re-encryption: external TLS terminates at the ingress, then a second session runs to the pod [6]. For that annotation to transfer, something inside the pod has to end the second session. The sample routes to `api-service` on port 8443 [7], and that port has to be a TLS listener holding a key pair. cert-manager will issue, rotate and store that key pair in a Secret with no manual steps in the path [10]. It will not make your application speak TLS.
Layer 2 is where the options thin out. Kubernetes does not encrypt data plane traffic, and a compromised pod can observe plaintext from other pods on the same node, which is why the post argues the pod boundary and not the VPC boundary is the relevant perimeter [3]. The only mechanism it offers for that hop is a mesh intercepting pod-to-pod traffic and wrapping it in mTLS, which it grants is both the strongest posture and the highest operational overhead, justified in regulated multi-tenant clusters and disproportionate for smaller estates [9]. Of the three data-path hops it inventories, two close with configuration and one does not [15]. So the mesh buys exactly one hop that no annotation reaches. The post also allows that edge termination only is legitimate for a single-tenant cluster with no regulated data, and that calling it TLS everywhere is not [8].
The database hop is the cheapest to close and the easiest to get wrong, because the enforcement point is not on the server. TLS enabled on RDS means the database is capable of TLS, not that it requires it, and a connection string missing `sslmode=require` or `Encrypt=True` connects in plaintext regardless [4]. That property lives in a secret, and none of these gaps appear in the diagram [1].
For internal service-to-service certificates the post recommends a self-signed CA issuer at 24-hour validity, on the argument that a 24-hour certificate has a far smaller blast radius than a one-year one if the key leaks [12]. Against the one-year cluster CA that kubeadm ships with no automated renewal [5], that is a 365-fold cut in how long a stolen key stays useful [14]. The bill is a daily dependency on the issuing controller instead of an annual calendar entry, and the two failures are not the same size: a missed kubeadm CA rotation stops `kubectl` cluster-wide [5], while a missed internal issuance stops one service's callers.
