Architecting for the cloud is becoming a highly desired skill set. Working as a consultant, I’m often in situations where clients are overwhelmed with questions about the cloud. How do I migrate my applications? How do I secure everything? How does it integrate with LDAP and DNS? What’s the best way to connect to the cloud? Will I need to rewrite my applications? How do I manage costs? While some of these vague questions can be answered with regurgitated marketing material, I feel a sense of duty to understand and explain these concepts at a deeper level. Some clients I work with already have a significant presence in the Cloud. Other clients have various pools of cloud resources and are looking to rationalize or provide a strategy around optimizing the sprawling resources. Because of recent exposure to cloud over the past couple of years, and due to the demand for practical knowledge of cloud architecture, a rigorous education program became an obvious next step for my career. At the beginning of 2019, I made a goal to become an AWS Certified Solutions Architect Associate. As of May 3rd, 2019 – that goal is achieved!
Many Clouds – Why AWS?
While I could have studied Google Cloud Platform (GCP) or Microsoft Azure, I chose to focus on Amazon Web Services (AWS) because of project work specific to AWS and because AWS is still the market leader in cloud. Nothing wrong with the other cloud providers, and in fact, it would be quite sensical to advance one’s knowledge in all of them. If you are only working with a single cloud provider, your choice is natural – you should study that one provider. However, if you’re a consultant or your job title is “Solutions Architect,” the demand placed on you is unfairly high, with the expectation that you can speak all clouds. In that case, I recommend just choosing one at-a-time to focus on. After doing a 3-month stint of GCP work in 2017, I can say that much of the theory and concepts are identical – you’ll mostly need to know the interworking of the provider-specific services when building real solutions or going for a certification.
How did I study?
I started studying regularly in February, putting in about 8-10 hours per week during nights and weekends. There are tons of great online courses out there, but since I already had an account with Linux Academy, I chose their coursework for much of my initial AWS studies. I went through all of the AWS CSA-A material on their site, took my time on all of the labs, and went through the practice exams at the end of the course. The instruction was excellent. I would have preferred a bit more practical demonstrations to solidify some of the more challenging topics, which seem to be covered more in depth in the CSA-P course. My opinion is purely subjective, of course, as I come from a network engineering background. Concepts like message queuing, sharding, analytics, and database architecture are not in my everyday wheelhouse. I spent extra time in my AWS account and Linux Academy’s Cloud Playground solidifying those topics. I would say that about 70% of my notes are from the material I learned on Linux Academy. Good stuff!
Next, I read through the following whitepapers, which I’d recommend for anyone preparing for the exam:
Lastly, I found an amazing site that I wish I had found earlier called Tutorials Dojo. They’ve authored a bunch of “cheat sheets” which are essentially just notes about certain topics. The sheets regarding scenarios or when to choose one platform over another are particularly helpful. They also have some formal training and practice exams you can buy on Udemy which may be worth checking out. Very helpful website – highly recommended.
Days leading up to the exam
When I felt somewhat comfortable in my knowledge, I booked the exam 10 days out. I figured that worse case if I fail, I will know what the exam is like and what my weaknesses are. I spent a few hours each night leading up to the exam going through all of my notes and reading the fantastic documentation on Tutorials Dojo – augmenting my notes as needed. I felt quite comfortable with the basics by this point, such as IAM, EC2, EBS, EFS, S3, VPCs, SGs, NACLs, Route53, ELB, ALB, RDS, and DynamoDB. So I spent most of my remaining time sharpening my knowledge in weaker areas like STS, KMS, MQ, Lambda, Kinesis, and CloudFront. I spent a reasonable amount of time memorizing the default values for various parameters. I went through any AWS service that I wasn’t familiar with in the AWS console and clicked on it to get a quick overview which came in handy during my exam.
Clicking the “end exam” button always gives me unwanted anxiety. I felt pretty good about my performance, but there were some questions that I wasn’t absolutely sure about. A huge sigh of relief as the short message “PASS” appeared on the screen. The exam was challenging, but fair. Some other vendor certification exams ask you nonsense questions that don’t truly test your knowledge about a concept or solution. In the AWS exam, I was asked about scalability, elasticity, security best practices, disaster recovery, automation, global application infrastructure, hybrid migrations, data retention, cost optimizations, architectural trade-offs, and numerous practical scenario questions. I wasn’t asked to know the parameters of some arbitrary field in some random service, given four possible answers that all look the same but are spelled differently. Instead, I was challenged to know when to use that field, and why that would be the best action for the particular guidelines.
Overall, the AWS CSA-A certification journey was a pleasant and rewarding one, from the early stages of branching out of my comfort zone with database architecture, to the positive experience of the exam itself. I feel much more confident in my ability to have effective conversations with clients regarding AWS architecture. Good luck to anyone on a similar journey – I’m certain you will succeed!