Certifications mattered to me because they got me out of theory and into the tools.

Before I had any AWS certifications, cloud felt abstract. I could read articles and watch videos, but I did not yet have instinct for where things lived in the console, how permissions failed, or what logs looked like when something broke. Studying for certifications gave me a reason to sit down and work through that gap instead of staying in the shallow end.

What the certifications actually did

During my AWS Cloud Support internship, I finished two certifications in a twelve-week window: AWS Certified AI Practitioner (Credly badge) and AWS Certified Solutions Architect Associate (Credly badge). Both were done by week seven.

Here is a quick comparison of the two certifications:

CertificationLevelFocusExam formatPrep time
AWS Certified AI PractitionerFoundationalAI/ML services, responsible AI65 min, 50 questions, multiple choice~3 weeks
AWS Certified Solutions Architect AssociateAssociateArchitecture, services, best practices130 min, 65 questions, multiple choice~5 weeks

Source: AWS Certification overview

That did not make me an expert. It did mean I was spending every day inside AWS. I was exposed to EC2, S3, RDS, IAM, Lambda, DynamoDB, CloudWatch, networking, permissions, logs, and runbooks (Source). The exams were layered on top of the work I was already doing.

Here are the core AWS services I worked with daily during the internship:

  • EC2 — virtual machines for compute workloads (Source)
  • S3 — object storage for files, backups, and static sites (Source)
  • RDS — managed relational databases (Source)
  • IAM — identity and access management for permissions (Source)
  • Lambda — serverless functions that run without provisioning servers (Source)
  • DynamoDB — managed NoSQL database for key-value workloads (Source)
  • CloudWatch — monitoring, logs, and alarms for AWS resources (Source)

Outside work hours, I used Stephen Maarek’s Udemy courses to structure prep (Source). I ran practice exams, looked up explanations for missed questions, and found YouTube breakdowns when I needed a different voice. The question pools change, so I made sure I was looking at updated material. The loop was simple: test, find gaps, review, test again.

Here is the study loop I followed each week:

  1. Take a practice exam — simulate real conditions, no notes
  2. Review every missed question — look up the AWS docs for the service in question
  3. Fill the gap — read the official AWS documentation or watch a targeted YouTube explanation
  4. Re-test — run another practice exam to confirm the gap is closed
  5. Repeat — until consistently scoring 90–100%

I will be direct: I memorized the practice exams. I ran the test banks until I was scoring consistently in the 90–100% range. By the time I sat the real exams, the format felt familiar.

The certifications came from daily AWS exposure during the internship, structured prep at night, repetition, and filling gaps as I found them. That is it.

Career progression checkpoint illustration for this section.

What the process gave me

The exam was just the checkpoint. The real value was spending weeks moving between AWS consoles, docs, guided labs, Udemy quizzes, YouTube explanations, and my own notes (Source).

I was not just looking at architecture diagrams. I was wiring services together in lab environments, watching them fail, fixing them, and reinforcing the same concepts through practice questions. That cycle built familiarity and confidence inside AWS.

It also changed how I approach problems in general. When something does not work, I go to logs, permissions, configurations, and data flow instead of guessing. That habit came from living inside AWS daily and reinforcing it through exam prep.

Here is the debugging approach I developed:

  1. Check CloudWatch logs — look for the first real error, not the last line (Source)
  2. Check IAM permissions — verify the role or user has the required actions (Source)
  3. Check configurations — security groups, VPC settings, resource policies
  4. Trace data flow — follow the request from origin to failure point

What certifications did not do

They did not make me a senior engineer. They did not give me production ownership experience. They did not replace real project work. They did not teach deep algorithms or low-level systems design.

Here is a clear breakdown of what certifications did and did not provide:

What certifications gave meWhat certifications did not give me
Comfort navigating the AWS consoleSenior-level engineering judgment
Familiarity with core AWS servicesProduction ownership experience
Ability to trace basic failuresDeep algorithms or systems design
Confidence with IAM and permissionsReal project delivery experience
A structured study frameworkHands-on debugging under pressure

What they did give me was comfort navigating AWS. I can open a new AWS account, find services without hunting through menus, understand where permissions live, and trace basic failures. That is the real outcome I walked away with.

Professional growth checkpoint illustration for this section.

How certifications helped with job searching

I will be straightforward: the certifications did not get me a job on their own. No recruiter called me because I had an AWS badge. What they did was get me through screening filters. Several applications asked specifically for AWS certification as a checkbox requirement. Having the badges meant I passed those filters instead of getting auto-rejected.

The bigger value was in interviews. When a hiring manager asked about cloud experience, I could speak concretely about IAM policies, S3 bucket configurations, Lambda cold starts, and CloudWatch log analysis. That confidence came from the daily internship work, but the certification prep reinforced it and gave me the vocabulary to talk about it clearly. Studying for the exams forced me to understand the naming conventions, service limits, and architectural patterns that come up in technical interviews.

The certifications also signaled something softer: that I was willing to sit down, study systematically, and finish something with a measurable outcome. In a field where a lot of people start things and abandon them, that signal matters. It is not the same as production experience, but it is not nothing.

What continuous learning looks like in practice

After the internship and the exams, learning did not stop. It just changed shape. I do not study for certifications every week. Instead, continuous learning is built into how I work on projects.

A typical week includes some combination of the following. When I hit a problem in a personal project, I read the official documentation for the tool or service involved instead of jumping to a tutorial. That habit came directly from certification prep, where reading AWS docs was the primary way I filled gaps. I spend time on GitHub looking at how projects I admire are structured. I read release notes for tools I use regularly, because breaking changes show up there before they show up in tutorials.

I do not have a fixed learning schedule. Like my project work, learning happens in response to need. When I want to build something I have never built before, the learning happens during the build. When I am between projects, I might watch a conference talk or read a long-form technical post. The key is that learning is not a separate activity from building. It is embedded in the work.

Recommended resources for other developers

These are the resources I have actually used and found valuable:

  • Stephane Maarek's Udemy courses — the best structured AWS certification prep I found. His practice exams are close to the real format (Source).
  • AWS official documentation — dry but accurate. When a practice exam question confused me, the AWS docs were the source of truth.
  • AWS Skill Builder — free official training content from AWS. Good for filling specific knowledge gaps without paying for a full course (Source).
  • Adrian Cantrill's courses — deeper than Maarek, more focused on architecture than exam prep. Good after you have the cert and want real understanding (Source).
  • GitHub repositories — reading source code of projects I use is one of the most underrated learning methods. You see real patterns, not toy examples.
  • MDN Web Docs — for anything frontend, this is still the best reference. I use it weekly (Source).

The pattern across all of these: official documentation first, structured courses for breadth, and real code for depth. Tutorials are fine for getting started, but they stop teaching you once you can read docs and source code directly.

Closing

I do not treat certifications as status symbols. For me, they were a structured way to get comfortable inside real cloud systems.

The badges are proof I went through the process. The real value was the experience I gained along the way.

Proof

References