How I Passed the AWS Certified Developer Associate

Finally, I passed the AWS Certified Developer – Associate certification.

There were too many services, too many small details, and too many exam scenarios that looked similar. But after many hours of study, practice exams, and writing notes in Notion, the concepts started to make sense.

This post is not only about passing a certification. It is about the process of going from confusion to understanding.

Why I decided to take this certification

I wanted to improve my skills as a cloud and full-stack developer.

I already had experience building applications, but I wanted to understand better how modern applications work in AWS, especially with:

• Lambda
• DynamoDB
• API Gateway
• SQS
• SNS
• EventBridge
• Kinesis
• Cognito
• CloudWatch
• X-Ray
• SAM and CloudFormation
• CodePipeline, CodeBuild, and CodeDeploy

The certification helped me connect these services in a more real way.

Before studying, I knew some services individually. After preparing for the exam, I started to understand how they work together in real architectures.

My biggest challenge: understanding AWS scenarios

The hardest part was not memorising definitions.

The hardest part was reading a scenario and understanding which AWS service solves the problem best.

For example, many questions looked like this:

An application needs to process events asynchronously, retry failed messages, and avoid losing data.

At first, I only saw a group of AWS names. Later, I learned to read the scenario and identify the pattern:

• Asynchronous processing → SQS, SNS, EventBridge, or Lambda async invocation
• Failed events → DLQ or retry configuration
• Ordered messages → SQS FIFO with MessageGroupId
• Streaming data → Kinesis
• Decoupling services → SQS
• Fan-out to multiple consumers → SNS + SQS

That change was important. I stopped trying to remember answers and started understanding the architecture.

Concepts that were hard for me

Lambda concurrency

Lambda concurrency was one of the concepts that confused me the most.

I had to understand that concurrency depends on how many executions are running at the same time.

For API Gateway, a simple way to calculate it is:

Concurrency = requests per second × duration in seconds

Example:

100 requests per second × 2 seconds = 200 concurrent executions

But for Kinesis or DynamoDB Streams, the thinking is different. Lambda processes records by shard, so shards become very important.

This was difficult at the beginning because I was mixing the general Lambda account concurrency limit with the concurrency created by event sources.

The key lesson was:

For request-based workloads, think about requests and duration.
For stream-based workloads, think about shards.

DynamoDB capacity and hot partitions

DynamoDB also took me time to understand.

At first, I thought DynamoDB was just a simple NoSQL database. But the exam goes deeper.

I had to learn about:

• RCU and WCU
• Strongly consistent reads
• Eventually consistent reads
• Item size
• Hot partitions
• GSI and LSI
• TTL
• On-demand vs provisioned capacity

One of the biggest lessons was that a bad partition key can create a hot partition.

For example:

user_id = "admin"

If too many requests go to the same partition key, one partition receives too much traffic while others are not used properly.

The simple rule I learned was:

A good partition key distributes traffic evenly.

I also learned that DynamoDB TTL does not delete items exactly at the expiration time. If an item expires in one hour, DynamoDB can remove it later. TTL is useful for automatic cleanup, but it is not a real-time delete system.

SQS FIFO and message ordering

I also struggled with SQS FIFO queues.

The part that helped me was understanding this:

MessageGroupId = controls order
MessageDeduplicationId = prevents duplicates

If I want messages to be ordered per user, I can use the user_id as the MessageGroupId.

Example:

MessageGroupId = user_123

This means all messages for that user are processed in order.

That was one of the small exam details that is easy to confuse.

Synchronous vs asynchronous invocation

I used to forget the difference between synchronous and asynchronous.

The way I remember it now is simple:

Synchronous = wait for the answer
Asynchronous = send and continue

Example:

• API Gateway calling Lambda usually needs a response, so it is synchronous.
• S3, SNS, or EventBridge triggering Lambda can be asynchronous.

This also affects errors.

With synchronous invocation, the caller receives the error.

With asynchronous invocation, Lambda can retry and send failed events to a DLQ or destination.

Cognito authentication

Cognito was another hard topic.

The biggest confusion was the difference between:

• User Pools
• Identity Pools

The simple explanation that helped me was:

User Pool = authentication
Identity Pool = AWS credentials

User Pools answer the question:

Who is the user?

Identity Pools answer the question:

What AWS resources can this user access?

That difference helped me understand many exam questions.

CloudFront and Lambda@Edge

CloudFront was interesting because it is not only about caching.

It can also help run logic close to users with Lambda@Edge or CloudFront Functions.

One example that helped me was premium video content.

If users need to be authorised before accessing videos, running logic close to the viewer can reduce latency.

This helped me understand why the exam sometimes chooses CloudFront + Lambda@Edge instead of sending every request back to a backend server.

S3 Object Lambda

S3 Object Lambda was another concept that felt strange at first.

The simple idea is:

Modify the object when it is being read, without creating another copy.

For example, imagine a document in S3 contains private information. Before returning it to the user, a Lambda function can remove the sensitive data.

That means we do not need to store a second redacted copy of the file.

SAM and CloudFormation

SAM helped me understand serverless deployment better.

The basic flow is:

Build → Package → Deploy

I learned that CloudFormation needs the Lambda code to be available, usually in S3, when deploying.

SAM makes this easier because it can build the project, package the artifacts, upload them, and deploy the infrastructure.

The important lesson was:

Infrastructure as Code is not only about creating resources. It is about making deployments repeatable and controlled.

CodePipeline, CodeBuild, and CodeDeploy

At first, the deployment services looked very similar.

Later, I understood them like this:

CodePipeline = orchestrates the workflow
CodeBuild = builds and tests the application
CodeDeploy = deploys the application

I also learned the difference between deployment strategies:

• All-at-once
• Rolling
• Canary
• Linear
• Blue/green

For me, the most important idea was traffic shifting.

Instead of sending all users to a new version immediately, we can send traffic slowly and reduce risk.

CloudWatch and X-Ray

For troubleshooting, I had to understand the difference between logs, metrics, and traces.

CloudWatch Logs = what happened
CloudWatch Metrics = numbers and performance
X-Ray = request path and latency

X-Ray was useful to understand distributed applications.

For example, if a request goes through API Gateway, Lambda, and DynamoDB, X-Ray helps identify where the delay or error happens.

I also learned that X-Ray annotations are indexed, so they can be used to search and filter traces. Metadata is useful, but it is not searchable in the same way.

KMS and encryption

KMS was another important topic.

I had to understand:

• SSE-S3
• SSE-KMS
• SSE-C
• Envelope encryption
• KMS key rotation
• Secrets Manager rotation

The difference that helped me was:

KMS rotation = rotates encryption key material
Secrets Manager rotation = rotates secret values like passwords

KMS automatic key rotation does not require a Lambda function.

Secrets Manager rotation usually uses Lambda because rotating a password needs custom logic.

Final reflection

Passing the AWS Certified Developer – Associate means a lot to me.

It represents discipline, consistency, and the ability to keep learning even when something feels difficult.

There were many moments when I felt confused. But every mistake helped me improve.

Now I feel more confident with AWS, serverless architectures, event-driven systems, and cloud development.

This certification is not the end.

It is just the beginning.

From confusion to certification — this is just the beginning.