Unit tests are a crucial part of the software development process. When used well they give you the confidence and sense of security needed to make changes without introducing bugs or regressions. When used badly they become a hindrance, slowing down development and encouraging bad practice. One common mistake is to write unit tests which reach too far and introduce fragility to your test suite.
Encryption is quite a hot topic these days. It's started to be vilified as "providing a safe means for criminals to communicate" by some not so familiar with the subject. There are even some proposals to ban it. While these are legitimate concerns, and ones that need to be tackled (although perhaps from a different angle), the truth is that providing a way to communicate free from eavesdropping is crucial in order to provide the services which underpin modern society. Losing this capability would nullify many of the technological advances of the last century and make the world a much more dangerous place.
The documentation surrounding AWS Aurora reserved instances is a little confusing. One of its main selling points is seamless Multi-AZ replication at the storage level; however, when you purchase reserved instances the Multi-AZ option is fixed at "No". Does this mean you can't run read replicas in another AZ if you're using reserved instances? Will you be charged the on-demand rate for your read replicas?
In order to combat spam and fraudulent email it's become common practice to deploy technologies such as SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) to provide a means for receivers to verify whether a message is from who it claims to be. Unfortunately, these are not foolproof and can still allow fraudulent messages to slip through. There's also no way of knowing what a receiver will do with messages that fail these checks and no way of knowing how effective they are. DMARC (Domain-based Message Authentication, Reporting and Conformance) goes some way towards improving this.
If you're working on or debugging a PHP application that creates files in the /tmp directory then you may find yourself needing to check for the existence of or the content of these files. On RHEL/CentOS 6 and below this would be as straightforward as listing the contents of /tmp or opening the file in your preferred text editor. On RHEL/CentOS 7 however you may be surprised to see that while your application can see its files fine, you can't.