Domain 2 — Security and Compliance

2.1 The shared responsibility model

The single most examined idea in this domain. AWS states it in two phrases worth memorising exactly:

**AWS is responsible for security of the cloud. The customer is responsible for security in the cloud.**

Security of the cloud is the infrastructure that runs every AWS service — the hardware, the software, the networking, and the physical facilities. You never patch a hypervisor, never guard a data centre door, never replace a failed disk.

Security in the cloud is everything you put on top: your data and whether it is encrypted, how you classify it, and the permissions you grant with IAM.

The line moves depending on the service

This is where the exam separates candidates. Responsibility is not a fixed split — it shifts with how much of the stack the service abstracts away.

Service type	Example	Customer looks after
Infrastructure (IaaS)	Amazon EC2	Guest operating system including updates and security patches, any software installed on the instance, and the firewall configuration
Abstracted services	Amazon S3, DynamoDB	AWS operates the infrastructure, the operating system and the platform; you access endpoints to store and retrieve data, and manage your data and its permissions

The pattern: the more managed the service, the less of the stack is yours. On EC2 you patch the OS. On Lambda there is no OS you can reach, so you don't. A question describing "who applies the security patch to the operating system" is really asking which service is involved.

Three kinds of control

AWS divides the controls themselves three ways, and the vocabulary appears in questions:

Inherited controls — you inherit them wholly from AWS. Physical and environmental security is the standard example.
Shared controls — both parties do their part at their own layer. Patch management is shared: AWS patches the infrastructure, you patch your guest OS.
Customer-specific controls — entirely yours, arising from what you are running rather than from AWS at all.

2.2 Security, governance and compliance concepts

Finding compliance information — AWS Artifact

AWS Artifact provides on-demand downloads of AWS security and compliance documents: ISO and PCI compliance reports, SOC reports, and certifications from accreditation bodies that validate AWS's security controls. You submit these to your own auditors or regulators as audit artifacts.

Artifact is also where you review, accept and track your agreements with AWS, and it is free of charge.

The exam framing: when a question asks where do I get AWS's SOC 2 report, the answer is Artifact. Note the direction — Artifact gives you documents about AWS's compliance. Documents proving your own compliance remain your responsibility, which follows directly from the shared responsibility model.

Encryption

Two states, and the exam expects the distinction:

Encryption at rest — data encrypted where it is stored, on a disk or in a bucket.
Encryption in transit — data encrypted while moving across a network, typically with TLS.

AWS Key Management Service (AWS KMS) creates and controls the keys. AWS CloudHSM provides dedicated hardware security modules for cases where regulation demands single-tenant hardware and direct key control.

Logging, monitoring and auditing — the three that get confused

Service	The question it answers
AWS CloudTrail	Who did what? Records API calls and account activity — the audit trail
Amazon CloudWatch	How is it behaving? Metrics, logs and alarms — the monitoring
AWS Config	How is it configured, and has that changed? Records resource configuration over time and assesses it against rules

The one-line separation to hold: CloudTrail is who, CloudWatch is how it is performing, Config is how it is set up. A question about tracing an unexpected resource deletion back to a user is CloudTrail. A question about whether every bucket has encryption switched on is Config.

2.3 Access management

The root user

When you create an AWS account you get a single sign-in identity with complete access to everything: the root user, identified by the email address the account was created with. AWS's guidance is unambiguous — do not use it for daily work.

MFA is enforced for root users by default, though it requires you to add it during account creation or when prompted at sign-in.

Tasks that genuinely require the root user include:

Changing certain account settings on a standalone account — and only certain ones. See the split below
Closing the AWS account
Restoring IAM user permissions, when the only IAM administrator has revoked their own
Activating IAM access to the Billing and Cost Management console
Registering as a seller in the Reserved Instance Marketplace
Configuring an S3 bucket to enable MFA Delete
Editing or deleting an S3 bucket policy or SQS resource-based policy that denies all principals — the classic lock-yourself-out scenario

"Change your account settings" is only half a root task

A question can turn on which setting, because the page splits them:

Requires root credentials	Does not
Email address	Account name
Root user password	Contact information
Root user access keys	Alternate contacts
	Payment currency preference
	AWS Regions

This applies to a standalone account — one that is not part of AWS Organizations.

Under AWS Organizations, most of this moves

Root credentials can be removed from member accounts entirely: the password, access keys, signing certificates and MFA. New accounts created in an organization have no root user credentials at all by default, and those member accounts cannot sign in as root or recover the password unless account recovery is enabled.

The management account or a delegated administrator then performs the privileged tasks centrally — closing member accounts, updating root email addresses, account names, contact information and Regions, and unlocking an S3 bucket or SQS queue whose policy denies every principal.

The exam framing to hold: a task that needs root on a standalone account often does not need it inside an organization, because the management account can do it instead.

IAM building blocks

User — an identity for one person or application
Group — a collection of users; attach a policy once and every member gets it
Role — a set of permissions assumed temporarily, by a service, an application, or a user from another account. No long-term credentials
Policy — the document granting or denying permissions. Managed policies are reusable — AWS-managed ones are maintained by AWS, customer managed ones by you. Custom policies is the exam guide's wording for the ones you write; IAM documentation calls those customer managed policies, or inline policies when attached directly to a single identity

Principle of least privilege — grant exactly the permissions needed for the task and no more. The exam uses this as the correct answer to almost any "how should permissions be assigned" question.

AWS IAM Identity Center provides single sign-on across multiple AWS accounts and applications, and is what AWS recommends for human access instead of creating IAM users per account. Federated identity means users authenticate with an existing identity provider rather than getting AWS credentials of their own.

For credentials that belong to applications rather than people, AWS Secrets Manager and AWS Systems Manager store them so they never end up in source code.

2.4 Security services

The four that get mixed up, distinguished by what they look at:

Service	Looks at	Finds
Amazon GuardDuty	CloudTrail management events, VPC flow logs, DNS logs	Threats and malicious activity — compromised credentials, cryptomining, malware, data exfiltration
Amazon Inspector	EC2 instances, container images in ECR, Lambda functions	Software vulnerabilities (CVEs) and unintended network exposure
Amazon Macie	Objects in Amazon S3	Sensitive data — PII, financial information, credentials — and buckets that are publicly accessible
Amazon Detective	Log data collected automatically	Not new problems — it investigates the root cause of findings the others raised

The memory hook: GuardDuty watches for an intruder, Inspector looks for an unlocked window, Macie tells you what valuables are in the room, and Detective works out what happened afterwards.

GuardDuty runs continuously with no scanning to schedule; Inspector likewise discovers and rescans automatically when something changes or a new CVE lands.

AWS Security Hub sits above them, consuming and prioritising findings from GuardDuty, Inspector, Macie and partner products, and checking your environment against security standards. Current service documentation calls it AWS Security Hub CSPM, while the exam guide's in-scope list still says AWS Security Hub — expect the shorter name in a question.

Protecting the edge

AWS Shield — DDoS protection
AWS WAF — web application firewall, filtering traffic by rules you set
AWS Firewall Manager — manages firewall rules centrally across accounts

Where AWS publishes security information

The AWS Knowledge Center, the AWS Security Center and the AWS Security Blog — the three the exam guide names by name. Third-party security products are available through AWS Marketplace, and AWS Trusted Advisor inspects your account and flags issues including security ones.

Source for this list: task statement 2.4, https://docs.aws.amazon.com/aws-certification/latest/cloud-practitioner-02/cloud-practitioner-02-domain2.html

Practise this with AWS Cloud Practitioner questions