I’ve been working in AWS for a few years now. The services I have experience with, I know pretty well. Obviously, there are far more AWS services that I haven’t used than ones I have, but I know my way around. I mean, if you’ve worked with a queue before, then you already understand SQS. Sure, there are more configurations and options, but at a high level, a queue is a queue.

API Gateway, S3, Lambda, EventBridge, and SQS let you build a lot of interesting things. This isn’t an advertisement for AWS. Building on the cloud is fun. What isn’t fun is getting certified in a cloud provider of your choice.

Honestly, it never occurred to me to get certified. My current job pushed it pretty hard. Probably because it’s a consulting firm and it looks better when they can say that X% of their engineers are certified. It looks good for the company, and it probably looks good for the individual too. If a client is looking at ten resumes and two of them have certifications, those two might have a slight edge. That’s how it works (unfortunately).

After going through the certification process, though, I came away with mixed feelings. If someone has a bunch of associate-level certifications, I don’t automatically see that as a strong signal. Not because the certifications are meaningless, but because building real systems is not the same thing as taking a test about building systems.

To be fair, I did learn a lot while preparing. I was exposed to services and features I hadn’t used before. But I didn’t build anything substantial with them. I didn’t deploy them, operate them, or deal with their failure modes. And in my experience, that’s where real understanding comes from.

I took calculus in college. I passed the exams and understood the material well enough at the time. But if you handed me a real problem today that required applying calculus in a non-obvious way, it goes without saying that it wouldn’t go well. The certification process feels similar. It teaches you what things are and when they’re supposed to be used. It doesn’t teach you what happens when things break, or when the correct answer isn’t obvious.

It’s easy to watch a certification course, take practice exams, and eventually pass the real exam. What’s harder is being handed a vague problem and having to design something that actually works. It’s easy to say “use SQS.” It’s harder to decide how retries should work, how to handle duplicate messages, how to monitor the system, and what happens when downstream services fail. That’s where the real knowledge is.

I don’t think I’ll pursue additional certifications anytime soon. Not because they’re useless, but because I’d rather spend that time building things. I’ll learn more from running real systems than I will from studying for another exam.

That said, I’ll absolutely keep the certification on my resume. It serves its purpose.