TCP/IP will feel academic for the first few days. Layers, packets, handshakes, routing tables -- it reads like a networking textbook because it is one. And then one day you will be debugging a production timeout caused by a misconfigured load balancer, or a WebSocket connection that drops every 60 seconds because of an idle timeout on a NAT gateway, and suddenly every page you read about TCP keepalives will feel like the most practical knowledge you have ever acquired.
DNS is the other one. Rails developers treat DNS as magic -- you point a domain at an IP and it works. Until it does not, and you are staring at TTL values and CNAME chains and wondering why half your users see the old server and half see the new one. Understanding DNS propagation, record types, and caching layers will save you from at least one catastrophic deploy in your career. Probably more.
Now, security. This is where most Rails developers have genuine blind spots, and I am not being gentle about it. You rely on Devise and has_secure_password and assume the framework handles the rest. But do you understand CSRF at the HTTP level, not just the Rails authenticity_token level? Can you explain what TLS 1.3 actually does, or why certificate pinning matters for mobile APIs? The OWASP Top 10 is not a DevOps checklist -- it is a list of ways your application can be exploited, and at least three of them are your responsibility as the application developer.
The hardest part of this module is accepting that security is not someone else's job. There is no "security team" at a 15-person startup. There is you, and there is the penetration tester who finds the IDOR vulnerability you left in your API because you forgot to scope a query to current_user. Learn this material like your users' data depends on it, because it does.