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 enough to get into trouble. 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, however, my current job encouraged (read: forced) obtaining one. 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 high level business person 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. 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. I studied what was going to be on the exam. 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 you’re required to use various services in ways that aren’t wrapped in a neatly wrapped problem statement.

It’s easier to watch a certification course, take practice exams, and eventually pass the real (associate level) exam. What’s harder is being handed a vague problem and having to design something that works in flexible ways. It’s easy to say “use SQS.” It’s harder to decide how retries should work, LIFO or FIFO, how to handle duplicate messages, how to monitor the system, and what happens when downstream services fail.

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, the certification is absolutely on my resume.