When I joined this AWS challenge, I expected one thing - a lot of new service names.
Amazon S3. Amazon RDS. Amazon DynamoDB. Amazon SNS. Amazon Bedrock.
Like many beginners, I thought the goal would be simple: learn what each service does, remember its definition, complete the challenge, and move on.
What I didn't realize was that each week's challenge was quietly building on the previous one.
Looking back, I don't think these three weeks were just about learning AWS. They were about changing the way I approach technical problems.
Week 1 - Stop Memorizing. Start Asking "Why?"
The first week's task was to understand five AWS services, explain them in our own words, think of real-life use cases, and share one feature we found interesting.
At first, I approached it the way I usually prepare for a new topic - read, understand, and remember.
But I noticed something.
The more I tried to remember definitions, the more everything started sounding similar. Then I changed my approach and asked myself one simple question:
"Why would someone even build this service?"
That single question made everything much easier to understand.
Instead of seeing Amazon S3 as just another storage service, I imagined the millions of photos and videos uploaded every second on platforms like Instagram or YouTube.
Instead of treating Amazon SNS as a notification service, I pictured a hackathon platform sending registration confirmations, mentor updates, deadline reminders, and final results to thousands of students.
Instead of memorizing what Amazon Bedrock does, I imagined building an AI assistant that could help students discover hackathons based on their interests.
Those examples were simply my way of connecting technical concepts with situations I could actually relate to.
That was my first mindset shift.
Technology becomes much easier to understand when you stop memorizing features and start thinking about the problems they were created to solve.
Week 2 - Knowing the Tool Isn't Enough
The second week's challenge felt completely different.
This time, we weren't asked to explain services.
Instead, we were given different scenarios and had to choose the most suitable AWS service, along with the reasoning behind our choice.
Initially, I expected every question to have one obvious answer.
It didn't.
I found myself comparing services, thinking about trade-offs, and asking questions like:
- Why is this service a better fit than another?
- What exactly is the requirement here?
- Am I solving the right problem?
For the first time, I realized that learning technology isn't just about knowing what different tools can do.
It's about understanding why one solution makes more sense than another.
Week 3 - Understand the Problem Before the Solution
The third week's challenge was probably my favorite.
Instead of directly choosing an AWS service, we were given bug scenarios.
Our task was to identify what had actually gone wrong, decide which AWS service could help, and explain what we would tell the development team to fix the issue.
This completely changed the order in which I started thinking.
Earlier, my first thought used to be:
"Which AWS service fits here?"
After this challenge, my first thought became:
"What is the actual problem?"
It sounds like a small difference.
But I think it's one of the most important lessons I've learned.
Because if you misunderstand the problem, even the best technology won't give you the right solution.
Looking Back
Three weeks ago, I would've looked at a problem and wondered, "Which AWS service should I use?"
Today, I'd probably ask, "What exactly is the problem I'm trying to solve?"
Instead of memorizing services, I try to understand why they exist.
Instead of searching for the "correct" solution immediately, I spend more time understanding the requirements.
Instead of jumping to conclusions, I try to identify the root cause first.
Looking back, I don't think these three weeks were really about AWS.
They were about learning a different way to think.
I know I've only scratched the surface of cloud computing, and there's still a lot left to explore.
But these challenges gave me something I'll carry beyond AWS.
Whether I'm working on an open-source issue, building a college project, participating in a hackathon, or learning a completely new technology, I think I'll always start with the same question:
"What problem am I actually trying to solve?"
Earlier, I used to ask,
"What does this technology do?"
Now I find myself asking,
"Why was this technology built in the first place?"
Surprisingly, that one question has made learning feel much less overwhelming and a lot more meaningful.
And for me, that's been the biggest takeaway from these three weeks.
Top comments (0)