How I passed the AWS Solutions Architect Associate exam

The AWS Solutions Architect Associate certification is one of the most sought after cloud certifications. It focuses on design of optimized solutions on the AWS cloud, taking into account costs, resiliency, performance and security.

I started studying for this certification back in 2021, then due to an increased workload at work, I had to put my certification study aside.

I came back to it in April 2025, studied for two months and passed the test in the beginning of June 2025

During the course of my study, I saw that many people have shared their study path and their tips in YouTube videos. So, I decided to share my path with some tips.

Study material

I used ACloudGuru AWS Certified SAA 2020 course, I purchased it a while back and used it when I returned to studying. I must say that this course, while very good in presentation, is outdated in content. It seems that ACloudGuru sold its content to Pluralsight and this course has not been updated the past few years. This meant that I had a significant number of AWS services to catch up on. 

My suggestion is to download the AWS SAA exam guide from AWS:

https://d1.awsstatic.com/onedam/marketing-channels/website/aws/en_US/certification/approved/pdfs/docs-sa-assoc/AWS-Certified-Solutions-Architect-Associate_Exam-Guide.pdf

Go over the services that you need to know for the exam and catch up on the ones that are not covered in your course. You can catch up by reading material from the AWS site or TutorialsDojo: https://tutorialsdojo.com/aws-certified-solutions-architect-associate-saa-c03/

I would also recommend watching some demos on YouTube I found this channel particularly helpful: https://www.youtube.com/@TinyTechnicalTutorials

Another options is to purchase the best selling course on Udemy for AWS SAA, by Stephane Maarek. 

https://www.udemy.com/course/aws-certified-solutions-architect-associate-saa-c03/?couponCode=ST16MT230625A

His course is highly recommended and also up to date.

I also used an AWS gpt on ChatGPT for studying and clarifying some services and their use cases.

Practice Exams

It is very important to take some practice exams before the actual exam, in order to prepare. You should get practice exams that reflect actual AWS exam questions, which are scenario based rather than pure technical. 

The exam questions present you with a scenario of either an on-prem application that you need to migrate to the cloud, a hybrid cloud and on-prem scenario or a cloud application that you need to optimize for either cost, high availability, performance or security.

There are several good sources for practice exams, they are not free but don’t cost much.

I used the TutorialsDojo practice exams which I purchased on Udemy:

https://www.udemy.com/course/aws-certified-solutions-architect-associate-amazon-practice-exams-saa-c03/learn/quiz/4394978#reviews

There are 6 practice tests in this bundle. You can take the tests in either exam mode, with a timer, or in practice mode, without a time limit, where you get the answer after each question. You get a detailed explanation for each question including the relevant links to the AWS documentation. It is important to go over these explanations for the questions that you got wrong. I found the TutorialsDojo practice exams to be harder than the real exam. So I think if you can consistently pass them, you should be able to pass the real exam.

I also used this free resource of practice exams from youtube:

 https://www.youtube.com/watch?v=FSsAff-bqyI&t=10118s&ab_channel=TechWithShapingpixel

Shapingpixel has hundreds of questions, which he goes over and give the answer and a short explanation after each question. The explanations are not as thorough as the TutorialsDojo explanations, but I found that his questions better represented the real exam questions.

There are also other practice exams you can purchase, Stephane Maarek has his own exam bundle and there are also exam bundled from WhizLabs and others.

Exam Tips

The exam has 65 questions, some of which have more than one answer. You should get 130 minutes for the exam, although I got 140, probably because I’m not a native english speaker. This means you have about 2 minutes for each question, you should be able to answer the questions than your know within 30 seconds or less. That should give you enough time for the questions that your need to think about or guess.

You can mark questions for review, then after you finish going over the 65 questions, you get a review screen with the questions that you haven’t answered and the ones you answered but marked for review.  You need to go over these questions one by one, once you go over a question and answer it, it disappears from the review screen. 

If you don’t know the answer and need to make an educated guess, remember the following:

1. Usually there are two very similar answers, one of them should be the correct one.

2. The answers always favor a solution that includes an AWS service, preferably a serverless one, rather than a custom solution.

Conclusion

While it is not easy to pass the exam on the first try, it is certainly possible if you put an effort into studying for the exam. I believe that 2-3 months of studying is a reasonable time, even if you are working a full time job.

Remember that even if you are an experienced architect or developer, you still need to study hard. You will have an advantage over a novice, but that will not guarantee your success.

Good Luck

The shared module microservice antipatten

 

The shared module microservice antipatten

Shared modules are a part of every medium sized software project. The different modules in your application need some common code, components, services, or utilities that are used across the application.

 Instead of duplicating this code in different modules, it's placed in the shared module to promote consistency, reduce redundancy, and simplify maintenance. It has been a common practice in software projects to package the shared module as an artifact and make it available to the application through a package manager. For example, in Java, the share module is written as a different code project, packaged as a jar and then pushed to the artifact repository, then the application can use it by adding a dependency and downloading it through the package manager. The same is done for different other languages. 

With the emergence of microservices, I have witnessed where in some projects, developers implemented the shared module not as a library but as a microservice. This results in other microservices having to call the share module microservice for common functions.

 

This is an antipattern. It introduces tight coupling between services, adds network latency, and creates a new point of failure. It also increases operational overhead with more deployment, monitoring, security, and resiliency requirements.

One common defense is that updating the shared module as a service avoids the need to redeploy all microservices. That sounds reasonable—until you consider the tradeoffs:

1. In the era of automatic deployments and devops, deployment of several microservices should not be such an overhead. It certainly should not force us to abort existing software engineering practices that have been around for years.

2. The overhead of deploying additional services does not equal the overhead that is introduced by adding an additional microservice. As mentioned, this presents the additional overhead of deployment, monitoring, security and resiliency. 

3. When making a change to a shared module, you will likely need to retest your application before deploying, since all modules accessing the shared module will be affected, whether the change breaks a contract or not. This will probably lead to additional fixes and deployments, so the thought that we can just deploy the shared module service without additional overhead is rather naive.

Unless there's a strong architectural reason to expose shared functionality as a service—like cross-cutting concerns that truly need runtime access—it's best to stick with well-established practices: package the shared module as a library artifact.

Why Tech Depth Still Matters – Even for Senior Architects

 

There’s a common belief in the industry: “As you move up, you should focus more on strategy and less on code.”

While strategy, communication, and big-picture thinking are crucial for architects, there’s one thing I strongly believe:

Tech depth still matters. A lot.

Here are some of the reasons why:

🔹 Bad abstractions create bad systems. If you don’t understand how databases handle transactions under load or how Kafka deals with failures, you might design a system that looks good on paper—but falls apart in production.

🔹 Developers respect architects who "get it." If you can debug a tricky performance issue or explain why a specific microservices pattern is a bad fit for a project, engineers will listen to you. If you only speak in slides and diagrams, they won’t.

🔹 Tooling moves fast, but fundamentals don’t. Kubernetes, serverless, event-driven systems—these are tools. But deep knowledge of distributed systems, concurrency, and scalability will make you a great architect regardless of the tech stack.

🔹 Hands-on experience keeps you relevant. The best decisions often come from personal experience, not just theory. Even if you don’t code full-time, keeping your hands in the tech—through prototypes, reviewing PRs, or experimenting—gives you an edge.

Yes, architecture is about trade-offs, alignment, and long-term thinking. But without real technical depth, those decisions can be shallow.

How to detect the “service sprawl” anti pattern in your microservices architecture.

The service sprawl is an antipattern in your microservices architecture, in which you have broken down your application into an excessively large number of very small services. While aiming for fine-grained control, it can lead to increased complexity in management, deployment, and communication, potentially outweighing the benefits.

I have seen this happen, especially in large IT organizations, that are trying to adopt microservices. It is very easy for developers and managers to fall into the everything-is-a -microservices pitfall.

So, how can you tell if your application, or company is implementing this anti pattern ?

One of the most obvious “red flags” which indicate that you have a service sprawl, is if you find that some of your developers are responsible for developing and maintaining several microservices at the same time.  Of course, it might be that you have an expert developer, working on several projects at once, but this is a red flag that is worth looking into.

There are two main reasons that this is a red flag for the service sprawl:

1. If each developer can develop and maintain several microservices at once, it likely means those microservices are probably too thin. While that might be justified, still, it’s a good idea to look into that.

2. If a single developer is developing several microservices in the application, it can also mean that this application does not suffer from the drawbacks of a monolith and maybe those services could be combined into a single application, without the problems that monoliths are notorious for. 

To avoid service sprawl, teams should regularly evaluate whether their microservices are delivering real separation of concerns and justifying the overhead they introduce. Not every boundary needs to be a service boundary. Sometimes, combining overly thin services into one  can simplify architecture without sacrificing modularity. The goal is not to have more services, but to have the right ones.