Well, managers aren't scientists looking for truth. They are people running businesses that need to stay afloat and get stuff done. There's a lot of wiggle room there, mostly due to time pressure (from a charitable perspective, less charitable: also because of company politics).
There are two things at play here:
The reality of what happens is that devs with limited experience are asked to do things far outside their comfort zone because they aren't staffed enough. This isn't on the dev, it's on the company and a reality when it comes to growth. People make mistakes.
The second thing is that the databases themselves should be secure by default but are not. That's on the developers of that software. DBs should require setting strong passwords on creation.
Aws should also warn users about exposing these services directly to the outside world instead of just within the vpc.
It's as simple as that. And at scale, it adds up to a lot of mistakes.
And for better or worse, much of the tech industry does not require extensive certification and training with checking and rechecking of every step. (And even aerospace makes mistakes.)
And, yes, junior people make even more mistakes. But I'm not sure the fix to that is to have junior people's every action be check and rechecked by a more senior person. It can be done. That's generally how things work in medicine for example. Along with stringent certifications. But I'm not sure how many people in tech would want that. It's a reasonable discussion to have. Maybe training wheels are taken off too early in many cases.
On the other hand, I would argue that there are way too many footguns hidden everywhere, like the default binding of docker mentioned here. So yes, a highly skilled IT security professional knows them all, but they are rare. And I think it should be possible to set things up securely in a straight forward way, for people with their speciality in other areas, of which there are plenty.
If networking 101 is a foot gun to you, I don't think you know enough to be responsible for anything important. I don't think there is a software fix for that lack of knowledge.
With so many 10x full-stack developers who're just looking to get sh done and clock out, it can't be otherwise. If managing a server becomes just another bullet point in a developer job, this is exactly what we get.
Sure I can deploy stuff, but you shouldn't trust me. Unfortunately many are not so honest or even aware of the complexity (unknown unknowns).
Yup...the same management are the ones that laid off the DBAs, system admins, network engineers, etc because "the cloud" hand waves all this stuff away now.
Where are you going to store the password?
I'm not saying it's rocket science but it does take consideration. Do you store it in a plain text file on the server? How do you deal with CI/CD? Do you run a separate service for one credential?
AWS itself has a Secrets Manager from which other authorized services can pull secrets. If it's an outside CI/CD platform then those usually also have a place to store credentials.
Don't get me wrong. I don't think anyone should skip this step. You need auth for your datastores.
I didnt need to get beyond there to see when you went wrong, and the bar for competence is not high across the board. Sadly I havent found a way to make money out of it, but you have to be aware of it to navigate the world safely.
Even if you forget that the cloud is the internet and that the entire internet can reach you over the internet, it doesn't take a genius to set up a password for a cloud service. I have no idea how many of these databases are honey pots, but finding open and vulnerable servers is depressingly simple.
I suppose it's kind of liberating to know that you can be dumb enough to fling patient data into an unprotected cloud server and still get a job in IT. The bar is really set that low.