I Had AWS Certifications. I Still Felt Like an Imposter.
How my first internship taught me that overcoming imposter syndrome is not about knowing everything, but about learning to solve real problems.
“What if they realize I don’t know enough?”
That was the question I kept asking myself during the weeks leading up to my first internship.
From the outside, everything seemed to be going exactly as planned. I had earned multiple cloud certifications, spent months learning AWS, and secured an internship as a Cloud Architect & DevOps Engineer at Safran Electronics & Defense.
Friends congratulated me. Recruiters started paying more attention to my résumé. I felt like I had accomplished something I had been working towards for nearly two years.
And yet, every time I thought about my first day, another thought quickly replaced the excitement:
What if they expect more than I can actually do?
Looking back, I do not think I was afraid because I lacked technical knowledge. I was afraid because I had never used that knowledge to solve a real problem.
I had learned how AWS worked.
But I had never built something that another person would genuinely depend on.
It took me several months to understand the difference.
Why I Started Getting Certified
I discovered cloud computing during my second year of engineering school.
At that point, I already had a solid foundation in networking, databases, and software development through my coursework, so cloud felt like the perfect field to explore. It brought together everything I enjoyed: infrastructure, automation, programming, and architecture.
Like many students, however, curiosity was not my only motivation.
I also wanted to stand out.
Every year, thousands of engineering students graduate with similar degrees, similar coursework, and similar internship experiences. When recruiters spend only a few seconds looking at a résumé, I wanted mine to give them a reason to stop scrolling.
I remember thinking:
If I start getting certified early, I will have an advantage over other students applying for the same internships.
It seemed like a simple strategy. The earlier I invested in cloud certifications, the more opportunities I would have later.
So I decided to prepare for the AWS Certified Cloud Practitioner certification.
Over the following weeks, I immersed myself in AWS. I learned about the shared responsibility model, the AWS Well-Architected Framework, cloud security, cost optimization, high availability, and dozens of services that were completely new to me.
For the first time, I was not learning because it was part of a university course. I was learning because I genuinely wanted to understand how modern applications were built.
After a few weeks of studying and countless practice exams, I finally booked the certification.
I was surprisingly nervous.
As a student, paying for a certification exam is not insignificant. Passing would validate weeks of work. Failing would mean not only disappointment, but another exam fee that I would have to justify.
When I finally saw the word “Pass”, I could not stop smiling.
Of course, the certification looked great on my résumé. But what mattered even more was the confidence it gave me. It was the first time I had tangible proof that I could independently learn a completely new technical domain outside of university.
Needless to say, I proudly told my classmates.
Looking back, I probably talked about it a little too much.
Going Beyond the Fundamentals
Passing one certification naturally made me want to aim higher.
A few months before starting my internship, I decided to prepare for two more certifications: AWS Certified Solutions Architect – Associate and HashiCorp Terraform Associate.
The Solutions Architect certification felt completely different from Cloud Practitioner.
Instead of simply discovering AWS services, I had to understand how they interacted with each other and, more importantly, why one architectural decision could be better than another.
My evenings quickly became a routine of studying networking concepts, storage strategies, service quotas, throttling behavior, fault tolerance, high availability, disaster recovery, and architectural trade-offs. Every mock exam exposed new weaknesses, which meant another evening spent revisiting documentation before trying again.
Two months later, I passed the exam with a score of 832 out of 1000.
That certification felt different. Cloud Practitioner had introduced me to AWS. Solutions Architect made me feel like I was finally beginning to think like an architect.
Around the same time, I also started learning Terraform.
Unlike my previous certifications, Terraform required me to spend much more time building than reading. I found myself writing infrastructure as code, deploying resources, breaking them, fixing them, and repeating the process until everything worked as expected.
It was incredibly satisfying.
Without really noticing it, I had started enjoying the practical side of cloud engineering much more than studying for exams.
I even began creating small personal projects on AWS. Some explored serverless architectures, others experimented with containers or simple web applications deployed using Terraform.
None of them were particularly large, and that became a source of frustration.
I kept comparing my projects to impressive architectures shared online. Because my projects were not huge, I convinced myself they somehow were not valuable.
Looking back, that was probably my biggest misconception.
Small projects are not small lessons. Every deployment teaches you something.
I just did not realize it yet.
When Your Résumé Feels More Impressive Than You Do
By the time my internship started, I had accumulated what I thought was everything I needed.
- Three cloud certifications
- Hands-on Terraform experience
- Several AWS projects
- A résumé I was genuinely proud of
Yet the closer I got to my first day, the more I questioned whether I belonged there.
The problem was not that I doubted my ability to study. I had already proven to myself that I could learn. The problem was that I had never worked in a professional environment.
There is a fundamental difference between deploying infrastructure for yourself and deploying infrastructure that other people will rely on.
Personal projects do not have deadlines. Nobody loses productivity if your architecture fails. Nobody asks why costs doubled overnight. Nobody depends on your deployment succeeding before Monday morning.
Professional engineering is different.
Suddenly, your technical decisions affect other people. That realization made every certification feel smaller. Not useless. Just incomplete. They had taught me concepts, vocabulary, and best practices. But they could not teach me what it felt like to take responsibility for a real system.
And that is exactly what frightened me.
I was convinced that, sooner or later, everyone around me would realize I was not as capable as my résumé suggested.
Today, I know that feeling has a name.
Imposter syndrome.
My First Real Project Changed Everything
A few days after arriving at Safran, my manager assigned me my first major project.
I was responsible for designing and deploying the cloud infrastructure supporting an internal machine learning hackathon.
At first, it sounded exciting.
Then the requirements started arriving.
Participants needed Jupyter Notebook environments running on Amazon EC2. Those environments had to be provisioned dynamically depending on demand, while GPU instances needed to be distributed across two Availability Zones to avoid exhausting regional capacity.
Every participant required access to shared storage through Amazon S3, and the competition itself needed a submission system with both public and private leaderboards.
On top of that, the infrastructure had to remain cost-conscious, which meant implementing budget alerts and monitoring from the beginning.
Note: Because the hackathon had a limited budget, each team was provided with two virtual machines. The first one was a “big” GPU-enabled VM, based on an Amazon EC2 G family instance, used for compute-intensive workloads but not meant to run continuously because of its higher cost. The second one was a smaller non-GPU VM, based on an Amazon EC2 T family instance, used for lighter experimentation and trial-and-error on the datasets without consuming costly GPU resources.
Unlike every project I had built before, this one was not theoretical.
There would be dozens of people depending on the platform. If something failed, someone else’s work would be interrupted.
That realization was intimidating.
But something unexpected happened. Instead of exposing everything I did not know, the project gradually showed me that I already had one of the most important skills: I knew how to learn.
Whenever I encountered something unfamiliar, I opened the documentation. When I was not sure about an architectural decision, I discussed it with my colleagues. Sometimes my first solution was not the best one. Sometimes it was.
What mattered was not always having the right answer immediately. What mattered was being able to reason through the problem until we found one.
That single project changed my perception of engineering more than any certification ever had.
Confidence Does Not Come From Knowing Everything
One of the biggest surprises during my internship had nothing to do with AWS.
It was discovering how experienced engineers actually work.
Before joining Safran, I imagined senior cloud architects as people who had every AWS service memorized. I thought expertise meant instantly knowing the perfect solution to every technical problem.
Reality was far more reassuring.
The engineers around me constantly challenged each other’s ideas. Architecture discussions were not about proving who was right. They were about understanding trade-offs.
Documentation was open almost all the time. Questions were encouraged. Assumptions were questioned. Decisions were justified.
Nobody expected anyone to know everything.
What they expected was curiosity, good reasoning, and the willingness to keep learning. That realization completely changed the way I viewed myself.
I stopped trying to become the engineer who already had every answer.
Instead, I focused on becoming the engineer who could find the right answer.
Ironically, that is when I finally started feeling confident.
What Real Projects Taught Me
Over the following months, I had the opportunity to contribute to several other projects.
I worked on a Retrieval-Augmented Generation application using Amazon OpenSearch and Amazon Bedrock, a microservices architecture built with AWS Lambda and AWS Step Functions, a containerized ticketing solution deployed on Amazon ECS, and a fully serverless web application using Amazon S3, Amazon DynamoDB, Amazon Cognito, and Amazon API Gateway.
Those projects taught me more than new AWS services.
They taught me how engineers collaborate, how architectural decisions are made, and how much value comes from discussing ideas with people who have different experiences.
They also changed the way I looked at my own learning journey.
Before my internship, I often thought of certifications and projects as separate things. Certifications were for validation. Projects were for practice.
Now I see them differently.
Certifications gave me structure. They helped me build a strong foundation, understand key concepts, and speak the same language as other cloud professionals.
Projects gave me context. They forced me to make decisions, deal with constraints, debug unexpected problems, and understand why those concepts mattered in practice.
Both were useful.
But they did not teach me the same things.
What I Would Tell Students Starting Today
If you are a student starting your cloud journey, my advice is simple: get certified, but do not stop there.
Certifications can be incredibly valuable. They give structure to your learning, help you understand cloud fundamentals, and can open doors that might otherwise stay closed.
But confidence rarely comes from passing an exam alone. It comes from building. Build small projects, even if they do not feel impressive.
Deploy something simple. Break it. Fix it. Add monitoring. Think about security. Estimate the cost. Write down what you learned. Share it with someone and ask for feedback.
A small project that you fully understand is more valuable than an impressive architecture you cannot explain.
And most importantly, do not wait until you feel completely ready before applying for opportunities.
You probably will not feel ready. That does not mean you are not capable.
Final Thoughts
If I could go back and give advice to the student who had just passed his first AWS certification, I would not tell him to stop pursuing certifications.
I would encourage him to keep going.
The AWS Certified Cloud Practitioner introduced me to cloud computing and gave me the confidence to explore further. The AWS Certified Solutions Architect – Associate taught me to think about architecture rather than individual services. Learning Terraform introduced me to Infrastructure as Code and pushed me to spend more time building than simply reading documentation.
Those certifications mattered.
They gave me the foundations that allowed me to contribute from my very first day.
What I would change is what happened after the certifications.
Instead of worrying that my personal projects were not impressive enough, I would simply build more of them. Instead of comparing myself to engineers with years of experience, I would remind myself that everyone starts somewhere.
And instead of waiting to feel ready, I would apply sooner.
Because engineering is not about knowing everything before you start.
It is about developing the ability to learn, adapt, ask better questions, and solve problems you have never encountered before.
Looking back, my certifications got me the interview. My projects gave me practical experience.
But working alongside talented engineers taught me the lesson that finally helped me overcome imposter syndrome:
I stopped trying to become the engineer who already knew every answer.
I started trying to become the engineer who could always find one.
If you are a student currently working towards your first certification or preparing for your first internship, keep learning, keep building, and do not let imposter syndrome convince you that you are not ready.
You might be more prepared than you think.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article