The lab centered on an HR assistant designed to reduce repetitive HR work, retrieving company policy information and handling employee requests, including leave and benefits submissions. That meant connecting an agent to both a knowledge base and tools that could invoke Lambda functions and persist requests in DynamoDB.

The full lab write-up lives here: aws-restart/agentic-ai

AI already pulls at my curiosity. Having more AWS knowledge to bring into this exercise gave my curiosity somewhere to go.

Revisiting “increased significantly”

In an earlier post about the AWS Generative AI Practitioner work, I wrote that my understanding of “RAG and MCP, along with how the surrounding components let an AI system retrieve information and actually take action, had increased significantly.”

Coming back to this material, I kept thinking: I can’t believe I used the words “increased significantly.” I knew that of course there was so so much more to learn, but there was so much underneath those concepts that I hadn’t even yet known how to question.

My broader understanding of AWS and IT had grown in the meantime. The relationships between services and their different levels of management were becoming clearer, so familiar configuration steps started raising new questions. I could look at a setting and begin recognizing some of the work it represented—and that there is so, so much I am incapable of recognizing.

Seeing the engineering behind the console

That led to a recurring thought while working in the console:

“There’s no way it’s actually this simple.”

Pointing one service at another can take very little effort. But what enables that connection? How much of that would I have to implement myself without the managed service?

I could start seeing how configuration fields represented substantial engineering: hosting, retrieval, tool integration, and access control. A few fields in the console can configure access to capabilities that would otherwise require substantial implementation and operational work — with AWS having already abstracted much of the machinery.

I now better understand the relationship between the simplicity of the interface and how much work sits underneath it. I pondered how understanding what had been provided would make the configuration itself more meaningful: why it existed, what it enabled, and which decisions remained mine.

Each answer gave me enough context to ask something I couldn’t have asked a few minutes earlier. I found myself spending as much attention on the questions emerging from a configuration as on completing the configuration itself.

Following the system beneath the settings

RAG: from question to answer

RAG became a particularly satisfying example. I worked through retrieval-augmented generation until I could follow a basic semantic retrieval path in my head:

Query text (question) → embedding model → query vector → vector store / search → relevant text chunks → question + retrieved context → language model → answer.

The embedding model converts the question's meaning into a numerical representation, called a vector, that can then be mathematically compared to vectors of document chunks. The search retrieves relevant text, and that text becomes context for the language model’s response. The embedding model and the language model have different jobs in that process.

That immediately opened another set of questions. How did the documents become searchable in the first place? Why split them into chunks? Where are the embeddings stored? What happens when the source documents change?

Following those questions took me into chunking, vector storage, and synchronization. When I wondered how synchronization worked—how the knowledge base could stay current as source documents changed—I could already picture an event-driven process for detecting those changes and updating its indexed content: detect a source-document change, trigger ingestion, and update the vector index. My earlier AWS learning was giving me enough context to reason through a system I hadn’t built myself.

I could now connect what happened when documents entered the knowledge base with what happened when someone asked the assistant a question. Amazon Bedrock Knowledge Bases was managing much of that workflow, which helped explain why the console steps could be so short.

MCP: connecting the agent to actions

MCP gives the agent a common interface to discover and call tools. AgentCore Gateway provided that interface to the backend: the agent could call a Lambda function to save an employee request in DynamoDB. Testing showed me the agent retrieving policy information, invoking action tools, and declining requests outside its HR scope. Seeing a submitted request appear in DynamoDB let me verify the action beyond the assistant’s reply.

With AWS managing retrieval, tool access, and agent hosting, I could focus on how the system fit together and the choices I still owned: its information, tools, permissions, instructions, and tests.

Understanding earlier work differently

That understanding has also started reaching backward into earlier work. I can think about serverless labs I don’t remember particularly well and still understand their architecture better now. Events, function execution, permissions, and data moving between services make more sense because I have more context for their relationships. Even when the individual steps have faded, newer knowledge helps me reconstruct what was happening.

This is part of why returning to the AI exercise felt so rewarding. The AWS knowledge I had gained elsewhere enabled deeper questions here, and working through those questions gave me another way to interpret systems I had already built.

Answers make new questions possible

There’s a progression here that I can now recognize in my own learning. An answer changes what I’m able to notice. What I notice raises another question, sometimes one I couldn’t have formulated before because I was missing the knowledge needed to even see it.

That’s what gives the earlier “increased significantly” wording its meaning to me now. My understanding had increased, and continuing to build on it eventually let me see how much more there was underneath RAG, MCP, and the surrounding system. I expect that to keep happening as I learn more.

I’m eager to return to this kind of build again with even more knowledge and see what discoveries are revealed, enabled by the questions I’ll be capable of asking.

I understand how little I know and how much more there is to know. I plan to close the gap day by day.

At the time, it worked, but the process still felt fragile. I was following the steps, but I did not have understanding of the system underneath them. Launching a basic EC2 instance and connecting to it with SSH is a beginner cloud task. The workflow itself is not advanced, but the way I experienced the task changed a lot, so this time it felt way different.

The first time, I was trying to keep track of several unfamiliar things at once: the EC2 console, key pairs, .pem files, WSL paths, chmod, public DNS names and IPv4 addresses... This time, those pieces had more context behind them, so the SSH took closer to two minutes than twenty.

That was the part that made the progress noticeable. The task had not become more complex. I had simply built more of the background knowledge needed to understand what was happening.

Linux CLI Navigation and Permissions

One of the biggest differences this time was that the local side of the SSH flow felt less confusing.

The command I used followed this general shape:

ssh -i ~/.ssh/ssh-practice-key.pem ec2-user@public-address

Earlier in my learning, a command like this felt more like something to copy carefully than something to understand. This time, I could read the parts more clearly.

When I first did this, even getting the .pem file into the right place felt like part of the mystery. The file downloaded to Windows, but I was connecting from WSL, so I had to understand where that file was from the Linux side and how to move it into the right location.

This time, that part was much easier. I understood that ~ refers to my Linux user’s home directory, and that ~/.ssh is the conventional place for user-specific SSH files. Moving the key there was not just “following a tutorial.” It made sense because my WSL environment was the client initiating the SSH connection, so the private key needed to live somewhere my Linux SSH client could use it cleanly.

That also made the permission step clearer.

chmod 400 ~/.ssh/ssh-practice-key.pem

The first time, a command like that felt like a magic fix. This time, I understood what it was doing. The .pem file is a private key, and OpenSSH will refuse to use a private key if its permissions are too open. The private key is proof of access, so it should not be readable by other users.

This go-round, I understood where and how to locate the downloaded file inside of Windows, and use it in my Linux environment, this orientation made the SSH setup feel less fragile because I was not just copying commands.

Not just knowing individual commands like cp, ls, or chmod, but understanding how to move through the filesystem, where files live, and how paths point from one place to another.

Networking Fundamentals Paid Off

I remember looking at the EC2 instance details and wondering why AWS showed IPv4 and IPv6 addresses, why some addresses were public and others were private, and why there was also a public DNS name.

This time, that part was clearer.

A public IP address or public DNS name is what my local machine can use to reach the instance from outside AWS. The private IP address is how the instance is identified inside its AWS VPC. DNS is a naming system that lets me use a name that resolves to an IP address instead of typing the address directly.

This also explains something that can look strange at first: I connected to the EC2 instance using a public address, but once I was inside the instance, the terminal prompt showed a hostname based on the private IP.

From outside AWS, I need a public route to reach the instance. Inside the AWS network, the instance has its own private identity.

Understanding that distinction made the address portion of the SSH command feel much less mysterious.

Seeing Both Sides of the SSH Relationship

The most clarifying part that helped make the key-pair model more concrete came when I looked around both sides of the connection.

On my WSL machine, my ~/.ssh directory contained files like the private key and known_hosts. On the EC2 instance, the ec2-user account had its own .ssh directory, and inside it was an authorized_keys file, which stored the matching public key.

When I connect, my SSH client uses the private key to prove that it matches one of the public keys authorized for that remote user.

The known_hosts file has a different role. It lives on the client side and records SSH servers that my machine has connected to before. That is why SSH shows a prompt the first time I connect to a new host. It is not asking whether my private key is valid. It is asking whether I want to trust and remember that server’s host identity.

That distinction helped the SSH trust model click:

Client side:
private key  -> proves I am allowed to log in
known_hosts  -> remembers servers I have trusted before

Server side:
authorized_keys -> lists public keys allowed to log in as that user

This helped me understand SSH beyond being an important tool for secure connection across systems, to a system with understandable parts.

Reusing the Same Key on a New Instance

The next morning, I launched another EC2 instance and connected using the same private key from the previous practice run. That helped confirm another part of the model.

The private key is not limited to one specific instance forever. It can work with any instance launched with the matching AWS key pair, because AWS places the matching public key on that instance during setup.

In that second connection, the instance was new and the public address was different, so SSH created a new known_hosts entry. But the authentication still worked because the key pair relationship was the same.

The instance changed. The address changed. The host identity was new. The key relationship still worked.

That distinction helped separate two ideas that are easy to blur together: the key used to authenticate me, and the host identity my machine remembers after connecting.

What Actually Changed

My ability to understand the pieces around the process.

The main thing that changed was not the SSH process itself. The process was still straightforward: launch an instance, make sure SSH is allowed, use the correct user, point SSH to the private key, and connect to a reachable address. But this time, supporting concepts were less foreign.

I understand the CLI better now, not just individual commands, but how to move through and understand where I am, and what is in the filesystem. I understand file permissions better, so chmod 400 no longer feels like a magic fix. I understand DNS, IP addresses, and the difference between public and private networking better. I also have a clearer mental model of private keys, public keys, authorized_keys, and known_hosts.

That is why this attempt felt so much easier.

The first time, SSH felt like it had too many moving parts: the EC2 instance, the .pem file, WSL paths, chmod, public addresses, private addresses, DNS, usernames, and host prompts. Because each piece was unfamiliar, the whole process felt larger than it actually was.

This time, those pieces grouped together more clearly. There was the machine I wanted to reach, the address my computer could use to reach it, the user I wanted to log in as, the private key I used to authenticate, and the local and remote SSH files that made the connection work.

Once I understood those parts, the task felt like a system I could reason through instead of a black box.

Originally published on LinkedIn on May 13, 2026.

• freeCodeCamp AWS Certified Cloud Practitioner course

• Tutorials Dojo (Jon Bonso) AWS CCP Practice Exams

• Official AWS CCP Practice Question Set

• An LLM (Like ChatGPT, or Claude)

The System

1. Use the freeCodeCamp course as an outline, and use an LLM in parallel as you go through each topic.

Course loop: learn topic -> test/clarify -> simplify -> next topic

2. Take the Official AWS CCP Practice Question Set for the very first benchmark.

3. After each practice exam, review weak areas through Jon Bonso’s topic-based exams.

Testing loop: practice test -> review -> weak area drill -> retest -> repeat

Keep repeating until you can score 80%+ in each domain.

4. Retake the Official AWS CCP Practice Question Set as your final benchmark.

My rule of thumb: 800/1000+ is a strong readiness signal.

• If you score below 800/1000, go back to step 3 and focus the weak areas.

• If you score 800/1000 or higher, you are probably ready. At that point, do not overthink it.

My Approach

When I passed the AWS Certified Cloud Practitioner exam, the biggest difference was not just the resources I used. It was the system I built around them.

The AWS CCP is an entry-level exam, but that can be misleading. There are still a lot of services, pricing concepts, security ideas, cloud terms, and shared responsibility details to sort through. If you study passively, it is easy to feel like you recognize the material without actually being able to explain it or apply it under exam conditions.

That was the main problem I wanted to avoid. I did not want to just watch a course, take notes, and hope enough of it stuck. I wanted a study process that kept the course active while I was learning, then exposed weak areas quickly once I moved into practice testing.

This is the breakdown of what I used, how I moved through the course, how I used ChatGPT, how I tested, and what actually got me across the line.

Resources I Used

My study stack was straightforward:

• freeCodeCamp AWS Certified Cloud Practitioner course

• Tutorials Dojo (Jon Bonso) AWS CCP Practice Exams

• Official AWS CCP Practice Question Set

• ChatGPT (for structured quizzing, review, and reasoning support)

I used the freeCodeCamp course as my main outline. It gave me the broad map of the exam: cloud concepts, AWS global infrastructure, compute, storage, databases, networking, security, billing, pricing, support plans, and the shared responsibility model. That structure helped me move through the material without constantly wondering what to study next.

The Tutorials Dojo / Jon Bonso practice exams became the real testing and feedback layer. That was where I started seeing the difference between topics I actually understood and topics I only recognized.

The official AWS CCP Practice Question Set was also valuable, but I used it later than I should have. In hindsight, I would have used it both at the beginning and near the end of the process because it felt very close to the real exam.

The Study System

The most important part of my process was that I did not use the course, practice exams, and ChatGPT as separate resources. I used them as parts of one study system.

That system had two phases.

The first phase was for moving through the course:

1. Learn a topic from the course.

2. Use ChatGPT to test and clarify the topic.

3. Convert complex topics into simple mental models.

4. Move to the next topic.

This kept the course from becoming passive. Instead of only watching the material, I used ChatGPT to check my understanding, simplify confusing concepts, and turn important ideas into language I could remember.

The second phase started after the course, when I moved into practice exams:

1. Take a practice test.

2. Review weak areas.

3. Separate true knowledge from lucky guesses.

4. Use ChatGPT to reason through weak topics.

5. Convert weak topics into simple mental models.

6. Retest.

The course is the map. Practice testing exposes areas that require reinforcement.

How I Used the LLM

ChatGPT was not a replacement for studying. It was the tool that made the process engaging and harder to fake.

That distinction matters because it is easy to read an explanation and think, “Yeah, that makes sense.” But recognizing an explanation is different from being able to recall the concept or reason through a question under pressure.

During the course, I mainly used ChatGPT for topic triage, quizzing, and compact mental models. After the course, I used it more for review: breaking down missed questions, clarifying confusing services, and understanding why one answer was better than another.

Topic Triage

This was most useful while I was moving through the course.

When I was studying a service or concept, I would ask ChatGPT to classify how important it was for the exam. The categories were simple: Essential, Less-essential, Optional, and Skip.

“Skip” was rare, but the classification helped me avoid treating every detail equally. That matters because AWS has a lot of services. For the CCP, the goal is not deep implementation mastery. The goal is foundational understanding: what services do, when they are used, and how they relate to cost, security, reliability, and cloud value.

The prompt was very simple — looked something like this:

I am studying for the AWS Certified Cloud Practitioner CLF-C02 exam.

For the topic below, classify its exam importance as:
Essential / Less-essential / Optional / Skip.
Then explain why, and generate a few beginner-friendly exam-style questions.

Topic:
[insert topic]

This helped me allocate attention better. Not every service deserved the same amount of study time. Some topics needed real repetition. Others only needed basic familiarity. That distinction made the process more efficient.

Delayed Reveal Quizzing

During the course, one of the most useful habits was delayed reveal quizzing. Instead of letting ChatGPT immediately explain the answer, I had it ask one multiple-choice question at a time and wait until I committed to A, B, C, or D.

The prompt looked something like this:

Ask one multiple-choice question at a time.

Do not reveal the correct answer until I choose A, B, C, or D.

After I answer, briefly explain why the correct answer is right
and why the other options are wrong.

This kept me honest. When the answer is revealed too early, it is easy to mistake understanding the explanation for knowing the answer. Delayed reveal made me choose before I could benefit from the explanation, which allowed me to better encode the information.

That exposed weak reasoning quickly. Sometimes I got the answer right for the wrong reason. Sometimes I narrowed it down to two choices but could not clearly explain the difference. Sometimes I realized I recognized a service name but did not actually understand what problem the service solved.

That kind of feedback was more useful than just reading another explanation.

Confidence Tagging

Once I started taking practice exams, I did not only mark answers as right or wrong. I also tagged my correct answers based on confidence:

• Confident

• Unsure

• Guessed

This mattered because a correct answer can hide a weak concept. Sometimes I guessed between two options. Sometimes one answer sounded more familiar. Sometimes I eliminated choices without fully understanding the service being tested.

Those answers can inflate the score without proving that the concept is stable. So after each practice exam, I treated “unsure” and “guessed” answers almost like wrong answers.

This made review much more useful because it showed me what still needed work, even when the score looked better.

Compact Mental Models

Compact mental models helped in both parts of the process. During the course, they helped me simplify new topics. During practice review, they helped me rebuild concepts I had missed or guessed on.

These were short phrases or simple explanations that helped me remember what a service does, when it is used, and what it is commonly confused with.

The prompt looked something like this:

Create a compact mental model for this AWS service or concept.

Make it short, memorable, and exam-focused.
Also include:
- what it is
- when to use it
- what it is commonly confused with
- one exam-style clue that points to it

Topic:
[insert topic]

As I questioned each topic, and went through more and more topics, ChatGPT gradually learned to create mental models that are particularly useful for my thinking style.

This was especially useful for services that sounded similar at first. The real benefit came from typing these mental models into my own notes. Thinking about how to write the note forced me to process the concept instead of only reading it.

The typing mattered because it turned review into active recall. I was not just collecting explanations. I was compressing them into language I could actually remember.

How I Used Practice Exams

Practice exams were where the system became measurable. I used Tutorials Dojo / Jon Bonso practice exams to find weak areas and track progress, but the key was not just taking tests repeatedly. The key was using each test as a diagnostic tool.

After each practice exam, I reviewed what I got wrong, what I got right but guessed, what I got right but felt unsure about, which domains were repeatedly weak, and which services or concepts kept showing up. Then I went back into focused review.

The loop became: practice test -> review -> weak area drill -> repeat

This made a big difference because practice exams can be misleading if you only care about the final percentage. A score can go up while parts of your understanding remain weak. Confidence tagging helped prevent that by forcing me to look underneath the score.

Score Progression

Here is what my progression looked like:

• First Jon Bonso randomized timed test: 57%

• After section-based loops: 74%

• After timed practice loops: 78%

• After notes and test review: 86%

• Official AWS CCP Practice Question Set: 724/1000

• Official exam: PASS — 837/1000

The score jump did not come from one magic resource. It came from repeated feedback. The first score showed me where I actually was. The later scores showed that the review loop was working.

By the time I took the official practice exam, I had already improved significantly. But I still think I took it too late. The official AWS CCP Practice Question Set felt very similar to the actual exam, so I would have gotten more value from using it earlier as a baseline and then again near the end as a final readiness check.

What I Would Do Differently

If I could redo the process, I would take the official AWS CCP Practice Question Set twice: once early as a baseline and once near the end as a final benchmark.

That would have given me a cleaner comparison point. Instead of only using third-party practice tests to measure improvement, I would have had an official reference point from the start.

I also would have adhered more to ChatGPT’s topic prioritization judgement, and not over-study low-value details. AWS has a lot of services, with an exam like this it is easy to fall into the trap of trying to memorize everything. For the CCP, the better move is to understand the major service categories, the common use cases, the pricing and billing concepts, the shared responsibility model, and the basic cloud value propositions.

The exam is broad, not deep, so prioritization matters.

What Made the Difference

Feedback.

The course helped me build the foundation. Topic-based practice exams showed me precisely what still needed work. ChatGPT helped me review that feedback, simplify difficult concepts, and turn them into explanations I could effectively encode.

The system kept me asking better questions:

• Do I actually understand this?

• Can I explain why this answer is right?

• Can I explain why the other answers are wrong?

• Can I simplify the concept?

My Recommended Study Plan

If someone were starting AWS CCP prep from the beginning, I would keep the plan simple.

First, use a full, free course like freeCodeCamp to build the map. Do not try to master every service on the first pass. The goal is to understand the main domains: cloud concepts, AWS global infrastructure, compute, storage, databases, networking, security, billing and pricing, support plans, and the shared responsibility model.

Second, start using an LLM for simple practice questions earlier than feels. Practice questions are how you find out what “ready” actually means. Do not wait until you feel fully prepared, because the practice itself is part of the preparation.

Third, review intelligently. Do not only review wrong answers. Review guessed correct answers and unsure correct answers too. Those are the areas where hidden weakness lives.

Fourth, turn weak areas into compact mental models that work for you. For each weak service or concept, ask: what is it, what problem does it solve, when would AWS expect me to choose it, what is it commonly confused with, what related services does it usually appear near, and what clue in a question points toward it?

Finally, immediately take the Official AWS CCP Practice Question Set upon completing the course, iterate primarily using Jon Bonsos topic-based exams, and then use the official AWS CCP Practice Question Set as a final benchmark. Use the last review cycle to clean up weak areas before exam day.

Final Takeaway

The AWS Certified Cloud Practitioner is not a deep technical architecture exam, but it is still valuable if you use it correctly.

For me, it was a quick win that helped me build momentum while giving me a clearer foundation around AWS services, cloud value, billing, security, and the shared responsibility model. More importantly, it helped me build a study system I can reuse.

The real lesson was learning how to turn a certification into an active study process.

Originally published on Medium on May 11, 2026.

Context

Goal: SSH into an Amazon Linux EC2 instance from WSL Ubuntu, following AWS docs:

Expected workflow:

1. Launch EC2 (Amazon Linux)

2. Download .pem key pair

3. SSH as ec2-user

Symptoms I hit (Run #1)

From WSL, SSH failed with errors like:

• identity file ... not accessible (wrong path / file not where I thought)

• Permission denied (publickey) (key not usable or didn’t get presented)

Root cause

I was running the SSH client inside WSL (Linux) but pointing it at a private key stored on the Windows filesystem via /mnt/c/....

Why this matters:

• /mnt/c is a Windows mount (NTFS)

• Windows permissions (ACLs) get translated/mapped when accessed from WSL

• SSH requires the private key file to be not accessible to group/others

• If SSH decides your key file is “too open,” it ignores the key and authentication fails

In other words: the key wasn’t reliably “Linux-private” while sitting under /mnt/c.

The fix (consistent)

1) Copy key into WSL filesystem

mkdir -p ~/.ssh
cp /mnt/c/Users/Administrator/Documents/projects/l2c/<key-name>.pem ~/.ssh/

2) Lock permissions

chmod 400 ~/.ssh/<key-name>.pem

Confirm permissions look right:

ls -l ~/.ssh/<key-name>.pem
# expect: -r-------- ...

3) SSH in

ssh -i ~/.ssh/<key-name>.pem ec2-user@<public-dns>

Success looks like:

[ec2-user@ip-172-31-xx-xx ~]$

Run #2: “UNPROTECTED PRIVATE KEY FILE” confirmation

When I intentionally tried to use the key directly from /mnt/c again to test my understanding, I hit:

• WARNING: UNPROTECTED PRIVATE KEY FILE!

• Permissions ... are too open

That warning is SSH explicitly saying: “I will not use this key.”
Copying into ~/.ssh + chmod 400 resolved it immediately.

Quick notes on chmod 400 vs chmod 600

• chmod 400 = read-only for you (-r--------)

  • Ideal for .pem keys (SSH only needs to read it)

• chmod 600 = read/write for you (-rw-------)

  • Useful for sensitive config files you edit (e.g., ~/.aws/credentials)

What I learned

Tools run inside an environment. Files are governed by that environment’s permission model.
If SSH is running in WSL (Linux), your key needs to be a Linux-private file (best: in ~/.ssh) with Linux permissions.

References

• AWS EC2: Connect to your Linux instance using SSH — https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connect-linux-inst-ssh.html

• Cloudflare: What is SSH? — https://www.cloudflare.com/learning/access-management/what-is-ssh/