Step 3 — Security & Responsibility

Ask any long-time AWS trainer which single concept trips up the most Cloud Practitioner candidates, and they’ll say the same thing: people assume AWS secures everything for them. It doesn’t. Security on AWS is a partnership with a clearly drawn line, and almost every security question on this exam is really just asking you where that line sits.

The Shared Responsibility Model

The idea is simple once it clicks: AWS secures the cloud itself, you secure what you put in the cloud.

             AWS is responsible for:              YOU are responsible for:
             ────────────────────────             ────────────────────────
             Physical data centers                Your data and how it's classified
             Hardware and host infrastructure      Identity and access management
             Network infrastructure                Operating system patches (on EC2)
             Virtualization layer                  Firewall / security group configuration
                                                    Client-side and server-side encryption

The exact split shifts depending on the service. With EC2, you’re managing more — the guest operating system, any software you install, network configuration through security groups. With a fully managed service like DynamoDB or RDS, AWS absorbs more of that burden — you’re mainly responsible for your data and who’s allowed to access it.

A helpful mental shortcut: the more “managed” a service is, the more responsibility shifts to AWS. The more raw control you have (like a bare EC2 instance), the more responsibility sits with you.

IAM: Controlling Who Can Do What

IAM — Identity and Access Management — is the system governing every action taken inside an AWS account. At the foundational level, you don’t need to write policies yourself, but you do need to know what each building block represents.

Root user
   │  (the email address that created the account — extremely powerful, rarely used day to day)
   │
   ├── IAM Users        → individual identities for people or applications
   │
   ├── IAM Groups        → collections of users, given permissions once, shared by everyone in the group
   │
   ├── IAM Roles         → temporary permissions assumed by a user, application, or AWS service
   │
   └── IAM Policies       → JSON documents that define exactly what's allowed or denied

Users represent an individual person or application that needs to sign in. Groups let you manage permissions in bulk — attach a policy once to a group, and every member inherits it, instead of repeating the same policy on ten different users. Roles are different from users in one key way: nobody logs into a role permanently. A role is assumed temporarily — an EC2 instance might assume a role to read from an S3 bucket, or an employee might assume a role to get elevated access for a specific task, then have it expire.

Policies are the documents that actually spell out permissions — which actions are allowed, on which resources, under which conditions. You don’t need to write policy JSON for this exam, but you should recognize that a policy is what turns a user or role from “exists” into “can actually do something.”

A useful phrase for remembering the pattern: users are who you are, groups are how you’re organized, roles are what you can temporarily become, and policies are what you’re allowed to do.

Root Account Best Practices

The root user is created the moment you set up an AWS account, tied to the original email address, and it can do literally anything — including closing the account. That power is exactly why AWS’s guidance is consistent and blunt:

Don’t use the root account for everyday tasks. Create an IAM user (or use IAM Identity Center) for daily work instead.
Enable MFA (Multi-Factor Authentication) on the root account immediately.
Store root credentials somewhere secure and don’t share them.
Use the root account only for the small number of tasks that genuinely require it, such as changing the account’s support plan or closing the account entirely.

If an exam question asks “what is the most secure way to grant access to a new employee,” the answer is never “share the root credentials” and never “log them in as root.” It’s some form of IAM user, group, or role.

Multi-Factor Authentication (MFA)

MFA requires a second proof of identity beyond a password — typically a rotating code from a virtual authenticator app, a hardware security key, or a code sent to a registered device. The logic is straightforward: even if a password leaks, an attacker still can’t get in without that second factor.

AWS recommends MFA on the root account without exception, and strongly encourages it for any IAM user with meaningful permissions. When a question describes a security incident caused by a leaked password, the “how could this have been prevented” answer usually points straight at MFA.

Encryption Basics

Encryption on AWS breaks down into two states, and the exam expects you to know the difference:

Type	What it protects	Example
Encryption at rest	Data sitting in storage	An encrypted S3 bucket, an encrypted EBS volume
Encryption in transit	Data moving across a network	HTTPS/TLS between a browser and a web server

AWS Key Management Service (KMS) is the service most commonly mentioned for managing the encryption keys behind at-rest encryption — you don’t need its internal mechanics for this exam, just recognize it as “the service that manages encryption keys” when a scenario mentions protecting stored data.

You should also be comfortable with the general idea that many AWS services offer encryption as a checkbox or a default setting rather than something you build from scratch — the exam is testing awareness that encryption options exist and are commonly enabled, not how to implement cryptography.

DDoS Protection with AWS Shield

A Distributed Denial of Service (DDoS) attack tries to overwhelm a system with traffic until it can no longer serve legitimate users. AWS Shield defends against this at two levels:

AWS Shield Standard
  - Automatically enabled for every AWS customer, at no extra cost
  - Protects against the most common, most frequent network and transport layer attacks

AWS Shield Advanced
  - Paid tier, subscription-based
  - Adds enhanced detection, 24/7 access to a specialized response team,
    and cost protection against scaling charges caused by an attack

If a question describes needing extra DDoS support with direct access to AWS’s response team, that’s Shield Advanced. If it’s just asking “does AWS provide any baseline DDoS protection automatically,” the answer is Shield Standard, and it applies to everyone by default.

Compliance and AWS Artifact

Organizations in regulated industries — finance, healthcare, government — often need documented proof that AWS meets specific compliance standards before they’re allowed to use it. That’s where AWS Artifact comes in: a self-service portal where you can download AWS compliance reports and agreements, such as SOC reports or evidence tied to standards like ISO 27001 or PCI DSS.

Artifact doesn’t make your workload compliant on its own — remember the Shared Responsibility Model. AWS provides evidence that its side of the infrastructure meets a given standard; you’re still responsible for configuring your own applications and data handling in a way that satisfies the same standard.

Exam Focus: What Questions Test From This Step

Correctly splitting a described responsibility between AWS and the customer under the Shared Responsibility Model
Recognizing IAM users, groups, roles, and policies by definition, not by hands-on configuration
Root account best practices — never for daily use, always with MFA enabled
Knowing MFA adds a second layer of proof beyond a password
Telling encryption at rest apart from encryption in transit
Shield Standard (automatic, free, everyone) versus Shield Advanced (paid, enhanced, dedicated support)
AWS Artifact as the source for compliance reports, not a compliance guarantee by itself