6 AWS Certifications Later: What I Really Learned Along the Way

Six AWS certifications later, I can say that my understanding of cloud computing has changed significantly.

But not necessarily for the reasons I expected.

When I started this journey, my main goal was to build solid cloud and DevOps skills. I wanted to understand how modern cloud infrastructures work, how applications are deployed, and how teams manage systems at scale.

Coming from a background in QA and software validation, I already had experience with Linux environments, troubleshooting, automation, and working with development teams. However, cloud infrastructure was a different world, and I knew I had a lot to learn.

Today, after completing six AWS certifications and working on several hands-on projects, I want to share what this journey actually taught me — beyond exam preparation and certification badges.

1. Six Certifications, Six Different Perspectives

Each certification introduced me to a different aspect of the AWS ecosystem. More importantly, each one helped me develop a different way of thinking about cloud engineering.

Here are the six certifications I completed and what I took away from each.

AWS Certified Cloud Practitioner

This was my starting point.

It helped me understand the fundamentals of AWS: its global infrastructure, core services, pricing models, shared responsibility model, and cloud concepts.

At this stage, I was mainly learning the vocabulary and understanding how the different pieces of the AWS ecosystem fit together.

My takeaway: Before building anything, you need to understand the environment you're working in.

AWS Certified Solutions Architect – Associate

This certification changed the way I approached infrastructure design.

I started thinking beyond individual services and focusing more on architecture:

• How do you design for high availability?
• When should you choose one database solution over another?
• How can you make an application scalable and resilient?
• What are the trade-offs between performance, security, and cost?

I learned that there is rarely one perfect architectural solution. Every decision comes with trade-offs.

My takeaway: Cloud architecture is not about knowing as many AWS services as possible. It's about choosing the right services for the right requirements.

AWS Certified Developer – Associate

This certification helped me better understand the developer's perspective of AWS.

I explored how applications interact with AWS services, including storage, databases, messaging, APIs, authentication, and application deployment.

It also helped me understand the importance of application-level security, permissions, and service integrations.

My takeaway: Infrastructure and applications cannot be treated as completely separate worlds. Understanding how they interact is essential.

AWS Certified SysOps Administrator – Associate

This one brought me closer to the operational side of cloud engineering.

Monitoring, logging, troubleshooting, automation, resource management, and operational reliability became central topics.

I started paying more attention to what happens after an application is deployed.

How do you detect problems? How do you investigate failures? How do you maintain availability?

These questions are just as important as designing and deploying infrastructure.

My takeaway: Deploying an application is only the beginning. Keeping it healthy and available is another challenge entirely.

AWS Certified DevOps Engineer – Professional

This was probably one of the most challenging steps in my AWS certification journey.

The focus shifted towards automation, continuous integration and delivery, deployment strategies, infrastructure management, monitoring, and operational excellence.

It required connecting concepts from architecture, development, and operations.

I also realized how important it is to understand the complete software delivery lifecycle rather than focusing on individual tools.

My takeaway: DevOps is not simply about learning tools. It's about improving the way software is built, tested, deployed, and operated.

AWS Certified AI Practitioner

This certification introduced me to another important dimension of the cloud ecosystem: artificial intelligence.

I explored foundational AI and machine learning concepts, generative AI, foundation models, responsible AI, and AWS AI services.

It was a different learning experience from the infrastructure-focused certifications, but it helped me understand how AI capabilities are becoming part of modern cloud solutions.

My takeaway: Cloud engineering continues to evolve, and staying curious about emerging technologies is important.

2. What I Learned Beyond the Exam Objectives

Looking back, the most valuable lessons were not necessarily the ones written in the exam guides.

A few things became particularly clear.

AWS services are interconnected.

Learning S3, IAM, EC2, RDS, Lambda, or EKS individually is useful. But understanding how they work together to support a real application is much more valuable.

Security cannot be an afterthought.

Identity and access management, least privilege, encryption, network isolation, and secure authentication should be considered from the beginning.

Everything involves trade-offs.

High availability, performance, scalability, security, and cost optimization are not independent objectives. Improving one can sometimes affect another.

Knowing a service is not the same as knowing how to operate it.

You can understand how EKS works for an exam and still struggle when a pod cannot communicate with another service, a deployment fails, or an application starts running out of resources.

That last point leads to what I consider the most important lesson of this journey.

3. Certifications vs. Hands-On Experience

Passing a certification exam gives you structured knowledge. It validates your understanding of concepts and AWS services.

But it does not automatically mean you can design, deploy, troubleshoot, and maintain a production-ready infrastructure.

I realized that I needed to move beyond exam preparation and start building things.

That's why I started working on LibraryCorner, a personal DevOps project designed to put my learning into practice.

The project gradually evolved into a complete AWS infrastructure involving:

• Terraform: Modular infrastructure as code.
• Amazon EKS: Kubernetes cluster and application deployment.
• Amazon RDS: PostgreSQL database with Multi-AZ configuration.
• AWS networking: VPC, subnets, routing, and load balancing.
• Prometheus and Grafana: Monitoring and observability.
• Kubernetes HPA: Automatic scaling based on resource utilization.
• IAM and OIDC: Secure authentication and access management.

Building this project introduced challenges that certification preparation alone could not reproduce.

I had to understand how components interacted, investigate unexpected behavior, make architectural decisions, and consider operational costs.

I also started exploring questions that don't always have straightforward answers:

• What happens when a monitoring component goes down?
• How can I restore a database after a failure?
• How do I scale an application under load?
• How can I avoid storing long-lived AWS credentials in CI/CD pipelines?
• How much does the infrastructure actually cost?

These questions eventually became the subjects of several technical articles I published on Dev.to.

And this is where theory started turning into practical understanding.

4. What I Would Do Differently

If I could start my AWS certification journey again, I would change a few things.

1. Build projects earlier.

Don't wait until you've completed several certifications before opening the AWS console or writing your first Terraform configuration.

Start experimenting from the beginning.

2. Avoid collecting certifications just for the sake of it.

Certifications can provide structure and motivation, but the number of badges on your profile is not a measure of your practical ability.

3. Learn by troubleshooting.

Don't just follow tutorials where everything works perfectly.

Break things intentionally in a controlled environment. Investigate errors, read logs, understand failure scenarios, and try to fix them.

4. Document what you learn.

Writing technical articles forces you to explain concepts clearly. It also helps identify gaps in your understanding.

5. Don't underestimate the fundamentals.

Linux, networking, scripting, security, and operating system concepts remain essential. Cloud platforms abstract many things, but they don't eliminate the need to understand what's happening underneath.

5. What's Next?

Six certifications are not the end of the journey.

I'm continuing to deepen my knowledge of Kubernetes, infrastructure automation, cloud security, and DevSecOps.

I'm also working towards the Certified Kubernetes Application Developer (CKAD) certification to strengthen my practical Kubernetes skills.

More importantly, I want to keep building projects, experimenting with new technologies, and sharing what I learn along the way.

My background in QA and validation has also shaped how I approach this journey. Quality, reliability, automation, and troubleshooting are not concepts exclusive to testing. They are equally important in cloud and DevOps engineering.

Final Thoughts

If there's one thing I would like to share with anyone starting their cloud journey, it's this:

Don't make certifications your final destination. Use them as a starting point.

They give you structure, introduce you to important concepts, and help you understand the ecosystem.

But real learning happens when you start building, breaking, fixing, and improving things yourself.

Six AWS certifications later, I have a much better understanding of cloud engineering than when I started.

But I also know how much there is still to learn.

And that's probably the most exciting part of this journey.

Keep learning. Keep building. Keep experimenting.