AWS Solutions Architect Associate Training Course

Every security question on this exam is decided by a boundary. Sometimes the boundary is a subnet, sometimes it is an account, sometimes it is a compliance requirement written into the scenario. The most fundamental one, and the one that quietly determines whether an answer option is even your problem to solve, is the shared responsibility model.

Security of the cloud, security in the cloud

AWS is responsible for the security of the cloud: the physical data centers, the hardware, the hypervisor, the network fabric between facilities, and the managed service software that runs above them. You are responsible for security in the cloud: your data, your identity configuration, your network rules, your operating systems where you have one, and your encryption choices.

The practical value of the model on the exam is that it moves with the service. The more managed a service is, the more of the stack AWS covers, and the smaller your remaining surface becomes:

• On EC2, you own guest operating system patching, host firewall configuration, application code, and any agent you install. AWS owns nothing above the hypervisor.
• On RDS, AWS applies the database engine patches during your maintenance window and manages the underlying host. You still own the database users, the parameter group, the network placement, and whether the storage is encrypted.
• On S3, AWS operates the storage service itself. You own the bucket policy, the Block Public Access settings, the encryption configuration, and the lifecycle of the objects.
• On Lambda, AWS owns the runtime host and the runtime patching. You own the function code, its dependencies, its execution role, and its VPC placement.

Read the model in reverse when you evaluate an answer. If an option asks you to harden something AWS already owns — patching the hypervisor, encrypting the network link between Availability Zones, securing the physical media in a Region — it is a distractor. If an option quietly leaves your side of the line unaddressed, it is incomplete no matter how sophisticated it sounds.

The four pillars the exam is built on

SAA-C03 is organized into four design domains that mirror four of the pillars of the AWS Well-Architected Framework: security, reliability, performance efficiency, and cost optimization. The exam does not test the framework as a document, but it does test the judgment the framework encodes. A well-architected answer is rarely the most capable one; it is the one that meets the stated requirement with the least additional complexity, cost, and operational burden.

This matters because of how the questions are written. Most items describe a workload, state one or two hard constraints, and offer four options that are all real, working AWS services. Three of them would function. Only one satisfies the constraint. The constraint is usually a single clause: without managing servers, the data must not traverse the public internet, the team cannot change the application code, with the lowest operational overhead, the recovery point objective is fifteen minutes. Train yourself to find that clause before you look at the options.

Defense in depth is the design instinct being measured

AWS expects a secure architecture to enforce the same intent at more than one layer, so that a single misconfiguration is not a breach. A private database tier is typically protected by all of the following at once: it sits in a subnet with no route to an internet gateway, its security group accepts traffic only from the application tier's security group, its credentials live in a secrets store rather than in code, its storage is encrypted with a key whose policy names only the roles that need it, and its API activity is recorded in CloudTrail.

When a question asks how to improve the security of an architecture that already has one control in place, the answer is usually the layer that is missing, not a stronger version of the layer that already exists.

Least privilege and the identity-first mindset

In a traditional data center the primary control is the network — you decide what can reach what. In AWS the primary control is identity. Every single API call to every AWS service is authenticated and authorized by IAM before anything else happens. A user with unrestricted permissions can delete a database from a coffee shop without touching your VPC at all.

So when you evaluate a security scenario, ask the identity question first: which principal is making this call, what role is it assuming, and what is the smallest set of actions and resources that lets it succeed? Network controls come second and constrain the path, not the permission. This ordering is the single most reliable heuristic for the largest domain on the exam.

How to read a security scenario

A repeatable method for the thirty percent of the exam this module covers:

• Identify the principal — a human, an EC2 instance, a Lambda function, an account, an external partner. Each has a different correct mechanism.
• Identify the resource and where it lives — same account, another account in the same organization, a third party.
• Find the hard constraint — no long-lived credentials, no internet path, customer-managed key material, auditable, no code change.
• Eliminate options that solve a different problem, that require managing something the constraint forbids, or that grant broader access than the scenario needs.

Nearly every remaining lesson in this module is a specific application of that method. The services change; the method does not.