First of all..in a sense this is normal. On whichever side of the interviewing and job search process you might happen to be on, you'll invariably find yourself dumbfounded by the reality of how things work, no matter what other people might be experiencing:

1. If you're looking for a job: It can take years to get an interview, no matter how much some people say otherwise or have differing experiences. This was especially the case during Covid. It has always been the case. It doesn't matter that recruiters swear up and down that they have plenty of call for your skill set and eagerly talk with you for extensive amounts of time if they won't actually submit you for work that is entirely well within your wheelhouse. The search process on the candidate's side is fundamentally broken, and it always has been. Everyone knows that.
2. If you're interviewing candidates for a job: Your company's HR department is likely to send you resumes and cover letters of candidates who are hopelessly unqualified for the position, literally not even close, demand you interview them, and these candidates you interview are often amazingly, stunningly bad at being interviewed. Bad as in, when asked a basic question, pausing for 20 seconds then seemingly reading a Wikipedia entry only vaguely related to the question or seemingly reciting what's being said to them by someone else in their headset level of bad. You are forced by process to interview at least a certain number of these candidates. It is then a wonder that you are able to interview any candidates that are even sort of qualified.

Everyone goes into the process thinking that if they're an interviewer, that they can ask questions relevant to the job, and that they can do white boarding / design type questions/walk-throughs/pairing to get an idea about how the other person thinks and communicates, etc., and candidates think that that's the process as well.

That's partially a bad way of thinking of the process because it ignores all the filters and gatekeeping that happened along the way.

However it's also a bad way of thinking of the process because it still implies the notion of "right" answers, which still isn't the best way of thinking of even unquestionably right-or-wrong answers.

People come to where they are skill-wise from many possible paths, and all of us have different blind spots where there are areas we just sort of happened to never look at. It is really weird how that happens, but it happens all the time.

I've had highly skilled coworkers who were unaware of some extremely basic things that I swear I wouldn't consider it possible to be unaware of and still be a functional at their jobs. I was able to say "okay, here's how this works", give a basic foundation, clear up something they didn't know about or understand for years, and then they were aware of it enough for that not to be a stumbling block.

But at the same time, I was amazed that they had gotten so far without knowing something basic and fundamental.

Security groups in AWS are something like that. You can't get away from it if you're putting together EC2 instances yourself, say building their AMI's, using Ansible as part of that process, and making security groups for their autoscaling group, etc.

I've looked at security groups all the time in debugging AWS issues, and I've created them, modified them, etc. And yes, I do consider it a bread-and-butter type thing. Not having dealt with them in AWS is sort of like going to a grocery store and never having tied your shoes.

However, counterexample: In a previous job, I set things up so that our users with limited AWS permissions were able to self-service creating and using SQS queues, fiddling with IAM permissions so that they could do so. You know what I didn't work with when setting that up? I didn't work with security groups, because they don't come into play for SQS queues.

So what if a coworker who didn't know about security groups were tasked with doing such a thing? That coworker could have easily done the same thing, and...never had the opportunity to fill in that hole in their knowledge.

Alternatively, if I had made a Terraform module related to the EC2 autoscaling example, and assuming that the module "just worked", (which is a very reasonable assumption), it is entirely possible that if that coworker had needed to modify something in the Terraform module about the instances, or if they needed to modify the Ansible playbook I used in the image generation process, they may not have needed to look at how I created and specified the security groups.

Yeah, I kind of like to think of everyone sort of being tangentially aware of the existence of what's going on around them in things they make changes to, but not everyone does that, and it's kind of okay--in this example, that coworker would be focusing on the things that needed to be changed, *and* if our network was working so well that they didn't need to make network or firewall changes, and access control didn't have to be changed for networking reasons, that person could blissfully remain ignorant of how security groups work until they run into the need to make that change. (I realize this is a little bit like someone who doesn't bother doing defensive driving happening to still avoid accidents.)

*AND*, if someone like that did run into the need to make that change, it is something they could and would quickly learn, because honestly, security groups are one of the simplest concepts imaginable--it's just the name of a group of a few firewall rules bundled together, and it's only how AWS handles things. GCP does things differently.

Knowledge of security groups and stories about how a person has dealt with them is a green flag / sanity check that a person has worked with AWS, but the lack of knowledge of them doesn't disprove that a person has worked with AWS. At best, it only disproves that they've done certain types of end-to-end greenfield designs 100% by themselves and that's okay. If I were the interviewer, I might mark them down a tiny bit in my head, but only a bit--any other evidence that they've done real design-it-yourself or debugging in AWS would override that one thing, and I'd ask around their AWS experience in a way that would reveal how their lack of exposure to security groups was reasonable. On the other hand, if further questioning showed that they couldn't talk about anything, then that would show that they were lying about doing things in AWS themselves.

It's a clue, not a smoking gun.