AWS Solutions Architect Associate Study Update # 3

Well it’s been a bit since my last update but that’s mostly because of travel. I have not let up on the AWS SAA study. In this post I’ll provide an update on a few things I find interesting.

Areas of Study

I thought it would be nice to share the outline I am following while I prepare. I’m using a mix of the course by Adrian Cantrill, practice exams by WhizLabs, the SAA-CO2 Exam Guide, the AWS Well Architected Framework, and lots of lab time in the AWS Console.

1. AWS Accounts
2. Reviewed a bunch of Tech Fundamentals
   1. YAML
   2. JSON
   3. OSI Model
   4. NAT
   5. Subnetting
3. Several AWS Fundamentals
   1. Public vs. Private Services
   2. AWS Global Infrastructure
   3. EC2
   4. S3
   5. Default VPC
   6. CloudFormation
   7. CloudWatch
   8. DNS and Route53
4. IAM, Accounts, and Organizations
5. S3
6. VPC
7. EC2
8. Containers & ECS
9. Route53
10. RDS
11. EFS
12. ELB, ALD, NLB, ASG, GLB
13. AWS Lambda
14. API Gateway
15. SQS
16. Kinesis
17. Amazon Cognito
18. CloudFront
19. Direct Connect
20. Transit Gateway
21. VPN
22. Storage Gateway
23. AWS Secrets Manager
24. AWS WAF & Shield
25. CloudHSM
26. AWS Config
27. Amazon Macie
28. Amazon Inspector
29. Amazon GuardDuty
30. Amazon DynamoDB
31. Amazon Athena
32. Amazon RedShift

I know there is a lot there, but this is not an exhaustive list. There are several other topics that fit in this outline and if you take a training course you’ll pick all those bits up.

Points of Interest

So far I have come across some really interesting things. On thing I like is the application of resource-based policies. A resource-based policy is just that, a policy attached to a resource that lets you specify who has access to the resource and what actions they can perform on it. You can attach resource-based policies to things like S3 buckets, VPC endpoints and AWS Secrets Manager.

This is a simple example of how resource policies work. For example, When you look at the user policies, its pretty simple to see that User A only has list/read on Resource A. A resource policy could change that, but in this example it doesn’t. However for User B you can see they can list/read on both resources B and C, however the resource policy on Resource C says otherwise. Since this is an explicit deny on the resource policy it doesn’t matter what the identity-based policy says. Also, User D will have full access to Resource C since there is no explicit policy that negates the resource-based policy.

To get a more complete sense of how these policies work and what services support them have a look at the Identity-based policies and resource-based policies page.

One other little bit I picked up that I want to explore in a bit more detail is how to encrypt data in an S3 bucket with Server-Side encryption and KMS.

Next On the Agenda

Next on my agenda is a dive into EC2 followed by Containers and ECS.

I’ll be back next week with another update. In the mean time, if you are new to cloud networking have a look at the Getting Started with AWS page where you’ll find some tutorials that you can follow to get some hands on experience.

Until next week, Happy Labbing!