Chapter 1

Design Secure Architectures

AWS Certified Solutions Architect – Associate (SAA-C03) Study GuideBased on the official AWS SAA-C03 exam objectives

Security is the first thing the SAA-C03 exam tests and the last thing you can afford to get wrong in a real architecture. It carries the largest weight of any domain on the exam — 30% of your score — so this chapter is long by design. The good news is that AWS security concepts are logical and repeatable: almost every question boils down to a small set of questions — who is allowed to do what, how is data protected when it moves and when it rests, and how do you detect and respond when something goes wrong.

Think of securing an AWS environment the way you would secure a corporate office building. Identity management is the badge system that decides who gets through the front door and which floors they can reach. Encryption is the safe inside the locked room. Network controls are the fences and security desks. Monitoring services are the security cameras and alarm panels. This chapter walks through each of those layers in turn, always tying the theory back to what the exam actually asks.

By the end of this chapter, you should be able to look at a scenario — "a company needs a cross-account access pattern with no long-term credentials," or "data at rest in S3 must be encrypted with keys rotated yearly" — and immediately know which service answers it and which distractors the exam will try to tempt you with.

Identity and Access Management (IAM)

IAM is the foundation of AWS security. Before any data flows, before any server launches, every request in AWS must first pass through IAM: who are you, and are you allowed to do this? Every API call, every console click, every automated process is authenticated and authorized by IAM. There is no way around it, which is why the exam tests IAM so heavily.

At its core, IAM has four building blocks. Users represent people or applications that interact with AWS. Each user has a name and can have credentials attached: a password for console access, access keys for programmatic access, or both. Groups are simply collections of users — you attach permissions to the group once, and every member inherits them. Roles are identities with permissions attached, but unlike users, roles are not tied to a specific person; they are meant to be assumed temporarily. When someone assumes a role, they get short-term credentials that expire. Finally, policies are the documents that define permissions — JSON documents that say "allow" or "deny" for specific actions on specific resources.

The golden rule of IAM, and a favorite exam theme, is least privilege: grant only the permissions needed to do the job, and nothing more. AWS starts every new identity with zero permissions — an implicit deny. You then add explicit allows for what is needed. And no matter how many allows stack up, a single explicit deny always wins. That evaluation order is worth memorizing: default deny → explicit allow → explicit deny wins over everything.

Identity-based vs. Resource-based Policies

This distinction shows up on the exam constantly. An identity-based policy is attached to a user, group, or role — it answers "what is this identity allowed to do?" A resource-based policy is attached to the resource itself — an S3 bucket policy, a KMS key policy, an SQS queue policy — and answers "who is allowed to access this resource?"

The critical difference: resource-based policies can grant access to identities in other AWS accounts. Identity-based policies alone cannot reach across account boundaries. So when a question describes "Account A needs to let a Lambda function in Account B read objects from its S3 bucket," the answer involves a resource-based policy on the bucket (plus an identity-based policy on the Lambda's role). Remember it this way: cross-account access almost always needs the resource side to open the door.

IAM Roles and How They Are Assumed

Roles are the workhorse of AWS security, and the exam expects you to reach for them constantly. Because roles hand out temporary credentials, they eliminate the need to store long-term access keys in application code — one of the most common security mistakes. An EC2 instance that needs to read from S3 should be given an instance profile (which is just a role wrapped for EC2), not an access key pasted into a config file. A Lambda function gets its permissions from its execution role.

Assuming a role always requires a trust policy — a special resource-based policy on the role itself that says who is allowed to assume it. The trust policy might allow a specific IAM user, an entire AWS account, an AWS service like EC2 or Lambda, or even an external identity provider. When a question describes temporary access for an application, a service, or a partner account, the answer is almost always "create a role with a trust policy."

Permission Boundaries

A permissions boundary is an advanced feature that sets the maximum permissions an IAM identity can ever have, no matter what other policies are attached. Think of it as a ceiling: even if an administrator attaches a policy granting s3:* to a developer, a boundary that only allows s3:GetObject on one bucket keeps the developer constrained.

The exam tests this in delegation scenarios: "a company wants to let team leads create IAM users for their teams, but those users must never be able to exceed a certain privilege level." The answer is permission boundaries — the team lead can grant any permissions up to the boundary, and the boundary prevents privilege escalation. Note that a boundary alone grants nothing; it only limits. The identity still needs regular policies to get any permissions at all.

Service Control Policies (SCPs)

SCPs belong to AWS Organizations, the service that manages multiple AWS accounts under one umbrella. An SCP is attached to an account or organizational unit and defines the maximum permissions available to everyone in that account — including the account's root user. Like permission boundaries, SCPs grant nothing; they only filter.

The classic exam scenario: "the security team must ensure that no one in the development accounts can disable CloudTrail logging or leave a specific AWS Region." The answer is an SCP that denies those actions, applied to the development organizational unit. Because SCPs sit above everything in the account, even an administrator with full IAM permissions cannot override them. Remember the hierarchy of limits: SCP (account ceiling) → permission boundary (identity ceiling) → identity policies (what you can actually do).

IAM Access Analyzer

Even with careful policies, permissions drift. IAM Access Analyzer examines your policies and flags unintended access — most famously, S3 buckets or IAM roles that are reachable from outside your account or organization. It answers the question "who outside my trust zone can reach this resource?"

The exam also tests Access Analyzer's policy generation feature: it can analyze CloudTrail logs of what an identity actually did and generate a least-privilege policy matching that real usage. In a scenario like "refine an overly broad policy down to least privilege based on actual activity," Access Analyzer is the tool.

MFA — Multi-Factor Authentication

MFA adds a second factor — typically a time-based code from a virtual device or hardware token — on top of a password or access key. Two exam points matter. First, MFA on the root user is a non-negotiable best practice; the root user is the one identity that cannot be limited by SCPs or permission boundaries, so protecting it with MFA is critical. Second, policies can require MFA using a condition: "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}. A question describing "users may only perform sensitive actions when authenticated with MFA" is solved with an IAM policy condition, not by asking users nicely.

IAM Identity Center

IAM Identity Center (the successor to AWS SSO) is how workforces sign in to AWS. Instead of creating IAM users for every employee, you connect your corporate identity provider (like Microsoft Entra ID or Okta) to Identity Center, and employees get single sign-on access to multiple AWS accounts and applications. You assign permission sets — bundles of IAM policies — to users or groups per account.

The exam scenario is unmistakable: "a company with hundreds of employees needs centralized access management across 50 AWS accounts, integrated with their existing corporate directory." The answer is IAM Identity Center, not 50 sets of IAM users. It also supports MFA enforcement centrally and provides a single place to audit who can access what.

Cross-Account Role Access

Putting the pieces together, the standard cross-account pattern works like this: Account A (the resource owner) creates a role whose trust policy allows Account B to assume it, and attaches permissions to that role for the needed resources. A user or application in Account B then calls sts:AssumeRole, receives temporary credentials, and acts with the role's permissions. If the resource is S3, you may also need a bucket policy — but the role-with-trust-policy is the core mechanism.

The exam frequently adds the external ID condition to this pattern. When a third party (say, a monitoring vendor) needs access to your account, you put a unique external ID in the role's trust policy that only the legitimate vendor knows. This prevents the "confused deputy" problem, where a malicious party tricks the vendor into using its access against your account. If a question mentions a third-party vendor assuming a role, look for the external ID in the answer.

Encryption and Key Management with KMS

Encryption converts readable data (plaintext) into scrambled data (ciphertext) that is useless without the key. AWS distinguishes two states of data: in transit (moving across a network) and at rest (sitting on a disk). TLS handles data in transit; AWS Key Management Service (KMS) is the managed service that handles the keys protecting data at rest across nearly every AWS service — S3, EBS, RDS, and dozens more.

KMS never wants you to handle raw encryption keys yourself. Instead, you create a KMS key (the customer master key concept from older docs), and AWS services call KMS on your behalf to encrypt and decrypt. You control the key's policy — who may use it and for what — while KMS handles the secure storage and the cryptography.

Envelope Encryption

Here is the idea that makes KMS scalable, and the exam expects you to understand it. Encrypting gigabytes of data directly with a KMS key would be slow and would expose the key to heavy use. Instead, KMS uses envelope encryption: it generates a unique data key for each object, encrypts the data with that data key, then encrypts the data key itself with your KMS key. The encrypted data key is stored alongside the data.

Decryption reverses the process: KMS decrypts the data key using your KMS key, then the data key decrypts the data. The beauty is that your KMS key itself rarely touches large data — it only ever encrypts small data keys — and every object gets its own unique data key, so compromising one key exposes only one object. When a question asks why KMS generates data keys instead of encrypting data directly, the answer is performance and limiting the blast radius of any single key.

Key Policies, Grants, and IAM Policies

Every KMS key has a key policy — a resource-based policy that is the primary gatekeeper for the key. This surprises people: for most AWS resources, IAM policies are the main control, but for KMS, the key policy is mandatory and authoritative. An IAM policy can allow use of a key, but if the key policy does not also allow it, access is denied. Both must permit.

Grants are a second mechanism: they let you delegate specific key permissions (like encrypt or decrypt) to a principal temporarily, and AWS services use grants behind the scenes constantly. When you enable EBS encryption by default, for example, the EC2 service receives a grant on your key so it can encrypt volumes on your behalf. You will rarely create grants directly, but the exam may mention them as the mechanism services use to act on keys.

The exam's favorite KMS trap is cross-account sharing: "Account B's application must decrypt data encrypted with Account A's KMS key." The answer requires both the key policy in Account A to allow Account B and an IAM policy in Account B allowing the action. One side alone is never enough — remember this, because the exam will offer "update the IAM policy" as a tempting but incomplete answer.

Key Rotation

KMS supports automatic annual rotation for customer-managed keys: once enabled, KMS generates new key material every year while keeping the old material available so previously encrypted data still decrypts. Your applications change nothing — they reference the key ID, and KMS routes to the correct key version behind the scenes.

Two exam facts: rotation applies to the key material, not the key ID or policy, and AWS-managed keys rotate automatically on their own schedule (you cannot disable it). A question stating "encryption keys must be rotated every year to meet compliance" is answered by enabling automatic rotation on a customer-managed KMS key — not by manually creating new keys, which would break decryption of old data.

Secrets Management: Secrets Manager vs. SSM Parameter Store

Applications need credentials — database passwords, API keys, OAuth tokens. Hardcoding them is a security failure and an exam red flag. AWS offers two services for storing them, and choosing correctly is a classic exam question.

AWS Secrets Manager is the purpose-built secrets service. Its headline feature is automatic rotation: it can rotate a database password on a schedule (say, every 30 days) by coordinating with RDS, updating both the database and the stored secret so applications never break. It also supports cross-account access, fine-grained IAM policies, and replication across Regions.

SSM Parameter Store (part of Systems Manager) stores configuration data and secrets as parameters. Its SecureString parameter type encrypts values with KMS. The standard tier is free, which makes Parameter Store attractive for simple use cases — but it has no built-in rotation. (The advanced tier adds larger sizes and more throughput, still without native rotation.)

The decision rule the exam tests: need automatic rotation → Secrets Manager. Just need to store an encrypted value cheaply, with rotation handled elsewhere or not needed → Parameter Store SecureString. A question describing "database credentials must rotate every 30 days without application downtime" has exactly one correct answer.

Transport Security: ACM and TLS

Data in transit must be encrypted with TLS (the modern successor to SSL — the exam still sometimes says "SSL/TLS"). The certificate proving a server's identity is the linchpin, and AWS Certificate Manager (ACM) provisions, deploys, and renews those certificates for free.

The exam facts about ACM: certificates are free; they renew automatically if they are used with an integrated AWS service (CloudFront, ALB, API Gateway) and the domain validation record remains in place; and ACM certificates cannot be exported for use on servers outside those integrations — for EC2 instances needing a certificate installed directly, you would use ACM's private CA or a third-party certificate instead. A question asking for "free, auto-renewing TLS certificates for an Application Load Balancer" is ACM's home turf.

Remember the full picture: TLS (via ACM) protects data in transit; KMS protects data at rest. The exam loves asking which protects which, and the answer is never both from one service.

S3 Security

S3 is the most-tested storage service for security, because misconfigured buckets cause real-world breaches. S3 security has several independent layers, and the exam expects you to know each one and how they combine.

Block Public Access

S3 Block Public Access is the master kill-switch for public exposure. It can be set at the account level (recommended) or per bucket, and it overrides any bucket policy or ACL that would grant public access. The exam's rule is simple: when a scenario demands "ensure no S3 bucket is ever publicly accessible," the answer is Block Public Access at the account level — not auditing bucket policies one by one. Note that it blocks new public policies and ACLs, and can also block existing public access depending on the settings chosen.

Bucket Policies and Object Ownership

A bucket policy is S3's resource-based policy: JSON attached to the bucket controlling who can do what. It is the tool for cross-account access ("Account B may read from this bucket") and for enforcing conditions like "deny any upload that is not encrypted" or "allow access only from this VPC endpoint."

Object Ownership settings control ACLs. The recommended setting, Bucket owner enforced, disables ACLs entirely — the bucket owner owns every object, and access is managed solely through IAM and bucket policies. This is both the current AWS default for new buckets and the exam's preferred answer: it eliminates the entire class of "object uploaded by another account that the bucket owner cannot read" problems. If a question mentions simplifying S3 permissions or ACL-related confusion, the answer is disabling ACLs with Bucket owner enforced.

S3 Access Points

S3 Access Points let you create named network endpoints for a bucket, each with its own policy. Instead of one giant bucket policy trying to serve five applications, each application gets an access point with a tailored policy — much easier to audit. The exam tests this in "shared bucket, different permissions per application or team" scenarios, and in VPC-restricted designs where each access point policy limits access to a specific VPC.

Pre-signed URLs

A pre-signed URL grants temporary access to a private S3 object through a URL that embeds an expiration time and the signer's credentials. The classic use case: let users upload profile photos directly to your private bucket, or download a private file, without making the bucket public and without proxying the bytes through your servers.

Exam essentials: the URL creator must already have permission to the object; the URL inherits only the creator's permissions (it cannot grant more); and expiration is configurable up to 7 days for IAM-created URLs. A question describing "temporary, secure access to private objects for external users without AWS credentials" is a pre-signed URL question — do not confuse it with CloudFront signed URLs, which serve content through a CDN distribution.

S3 Encryption: SSE-S3, SSE-KMS, and SSE-C

S3 offers three server-side encryption modes, and the exam tests the differences relentlessly:

• SSE-S3 (AES-256): S3 manages the keys entirely. Free, simplest, no audit trail of key usage. The default for new buckets.
• SSE-KMS: keys managed in KMS — your keys, your policies, full CloudTrail audit trail, optional automatic rotation. Costs per API request. Required when compliance demands key control or auditing.
• SSE-C (customer-provided keys): you supply the key with each request over HTTPS, and S3 never stores it. Maximum control, maximum operational burden — you manage rotation, loss means data loss.

You can enforce encryption with a bucket policy that denies any PutObject without the s3:x-amz-server-side-encryption condition. The exam phrase "all objects must be encrypted at rest" is typically solved by SSE-S3 as the default plus a bucket policy denying unencrypted uploads; add KMS when the scenario mentions auditing or customer-managed keys.

EBS and RDS Encryption

EBS encryption protects EC2 volume data at rest using KMS. Key exam points: encryption happens on the EC2 host's hardware, so there is no meaningful performance penalty; snapshots of encrypted volumes are encrypted, and snapshots can be copied across accounts or Regions with re-encryption; and you can enable encryption by default for all new volumes and snapshots in a Region — the exam's answer to "ensure every EBS volume is encrypted without relying on developers to remember."

RDS encryption works similarly: enable it at database creation using a KMS key, and it covers the underlying storage, automated backups, read replicas, and snapshots. The critical limitation the exam loves: you cannot encrypt an existing unencrypted RDS instance in place. The workaround is to take a snapshot, copy the snapshot with encryption enabled, and restore a new encrypted instance from it. Memorize that migration path — it appears on the exam regularly. Also note that RDS encryption must be enabled at creation; there is no toggle afterward.

Both services can use the AWS-managed key or your customer-managed key; choose the customer-managed key when the scenario requires rotation control or cross-account sharing.

Network Security: Security Groups vs. NACLs

VPC network security has two layers, and confusing them is one of the most common exam mistakes. Security groups are stateful virtual firewalls attached to resources (EC2 instances, RDS databases, load balancers). Network ACLs (NACLs) are stateless firewalls attached to subnets.

Stateful means a security group remembers: if you allow inbound traffic on port 443, the return traffic is automatically allowed outbound — you do not need an outbound rule for the response. Security groups are also allow-only: there are no deny rules, and everything is denied by default. Rules reference ports, protocols, and sources that can be IP ranges or other security groups — referencing another security group ("allow traffic from the web-tier security group") is the clean, scalable pattern the exam rewards over hardcoding IP addresses.

NACLs are stateless: return traffic must be explicitly allowed, so a NACL permitting inbound port 443 also needs outbound rules for the ephemeral ports (1024–65535) carrying responses. NACLs support both allow and deny rules, evaluated in numbered order from lowest to highest, with an implicit deny at the end. They apply at the subnet boundary, affecting every resource in the subnet.

The exam's framing: security groups are your primary, everyday control (instance-level, stateful, allow-only); NACLs are the coarse subnet-level backstop, useful for explicit denies — like blocking a specific malicious IP across a whole subnet, which security groups cannot do.

Private Connectivity: VPC Endpoints and PrivateLink

By default, traffic from a VPC to AWS services (S3, DynamoDB, API Gateway) travels over the public internet — encrypted, but public. VPC endpoints keep that traffic on the private AWS network, which improves security and avoids NAT gateway data charges.

There are two types, and the exam distinguishes them sharply:

• Gateway endpoints are free and available for S3 and DynamoDB only. They work by adding a route to the subnet route table — no Elastic Network Interface, no security group involved.
• Interface endpoints (powered by AWS PrivateLink) create an ENI in your subnet with a private IP, cost hourly plus data processing charges, and support most AWS services plus third-party SaaS. They use security groups, and they resolve via private DNS.

PrivateLink also lets you expose your own service (say, an internal API behind a Network Load Balancer) to other VPCs or other AWS accounts without either side touching the public internet or peering VPCs. The consumer creates an interface endpoint to your service; neither VPC's CIDR ranges need to coordinate. The exam scenario: "share a service with partner accounts privately, without VPC peering or internet exposure" — that is PrivateLink.

Endpoint policies add a further control: a policy on a gateway endpoint can restrict which S3 buckets or actions are reachable through it ("this subnet's instances may only read from the logging bucket"). Combined with a bucket policy restricting access to the endpoint, you get a tight private-access design the exam loves.

Perimeter Protection: WAF, Shield, and Firewall Manager

AWS WAF

AWS WAF is a web application firewall that filters HTTP/HTTPS traffic in front of CloudFront distributions, Application Load Balancers, and API Gateway. It works with rules: managed rule groups from AWS (covering the OWASP Top 10 like SQL injection and cross-site scripting) or your own custom rules matching IPs, strings, regex patterns, request sizes, or geographic origin.

The exam positions WAF at Layer 7 — it inspects the content of web requests. "Block SQL injection attempts against the web application" or "rate-limit requests from a single IP" or "block traffic from specific countries" are all WAF scenarios. It is not a DDoS service and not a network firewall; it protects web applications from application-layer attacks.

AWS Shield

AWS Shield Standard is automatically enabled for all AWS customers at no cost, protecting against common network-layer (Layer 3/4) DDoS attacks like SYN floods. Shield Advanced is the paid tier ($3,000/month per organization) adding larger-scale DDoS protection, near-real-time attack visibility, integration with WAF at no extra request cost, and the DDoS cost protection — AWS credits you for scaling costs caused by a documented attack.

The exam's decision rule: standard web application needing L7 filtering → WAF. Concern about large volumetric DDoS attacks with cost protection and 24/7 response team access → Shield Advanced. They are complementary, not alternatives — a common exam design pairs CloudFront + WAF + Shield Advanced for a high-profile web application.

AWS Firewall Manager

AWS Firewall Manager centrally manages WAF rules, Shield Advanced, security groups, and Network Firewall policies across all accounts in an AWS Organization. You define a policy once — "every ALB must have this WAF rule group" — and Firewall Manager enforces it on current and future accounts and resources, automatically remediating drift.

The signal phrase is scale plus consistency: "ensure WAF rules are applied uniformly across 40 accounts and any new account automatically complies." That is Firewall Manager. It does not itself filter traffic; it orchestrates the services that do.

Threat Detection and Monitoring

Prevention eventually fails somewhere, so AWS provides detective services. The exam tests whether you can match each service to what it detects.

Amazon GuardDuty

GuardDuty is intelligent threat detection: you enable it with one click (per account per Region), and it analyzes CloudTrail logs, VPC Flow Logs, and DNS query logs with machine learning to find threats — compromised EC2 instances mining cryptocurrency, IAM credentials used from unusual locations, port scanning, communication with known malicious IPs. Findings are ranked by severity and can trigger automated responses via EventBridge.

Exam essentials: GuardDuty is threat detection from logs — it finds active malicious behavior, not misconfigurations. It takes no agents and needs no log pipeline built by you; enabling it is the whole setup. "Detect compromised instances or stolen credentials in use" → GuardDuty.

Amazon Inspector

Inspector scans for vulnerabilities: it assesses EC2 instances (via the SSM agent) and container images in ECR for known CVEs, missing patches, and — for Lambda — code-level issues. It produces prioritized findings with severity scores.

The contrast the exam tests: GuardDuty finds attacks happening now (behavioral); Inspector finds weaknesses an attacker could exploit (vulnerabilities). "Continuously scan container images for known vulnerabilities" → Inspector. "Detect an instance communicating with a known botnet" → GuardDuty.

Amazon Macie

Macie uses machine learning to discover sensitive data — especially personally identifiable information (PII) — in S3 buckets. It can tell you that a bucket contains passport numbers or credit card data you did not know was there, and it flags overly permissive bucket policies on buckets holding sensitive data.

The exam scenario writes itself: "a company subject to GDPR must locate all PII stored across hundreds of S3 buckets." That is Macie — not GuardDuty, not Config.

AWS Security Hub

Security Hub is the aggregator: it collects findings from GuardDuty, Inspector, Macie, IAM Access Analyzer, and partner products into one dashboard, normalized into a standard format and scored against compliance frameworks (CIS benchmarks, PCI DSS). It does not detect anything itself — it centralizes and prioritizes what the detectors find.

"Single pane of glass for security findings across accounts and services" → Security Hub. If a question asks which service generates a finding, the answer is never Security Hub.

Logging and Auditing: CloudTrail and Config

AWS CloudTrail

CloudTrail records who did what — every API call in your account: who called it, when, from which IP, and what happened. It answers "who deleted that bucket?" or "when was this security group changed?" Trails can log to S3, and log file integrity validation (via digest files) proves logs were not tampered with — important for compliance.

Two exam-critical distinctions. First, CloudTrail tracks management activity (API calls); it does not record data-plane details like the contents of an S3 GET — that is what VPC Flow Logs and CloudWatch cover in their own domains. Second, management events are free and always on (the last 90 days visible in the console), while data events (like individual S3 object accesses or Lambda invocations) are optional and paid — you enable them selectively because of volume and cost.

To satisfy "audit all API activity across the organization with tamper-proof storage," the answer is an organization trail logging to a dedicated, restricted S3 bucket with integrity validation and ideally in a separate audit account. And tying back to SCPs: the exam's classic guardrail question — "prevent anyone from disabling CloudTrail" — is answered with an SCP denying cloudtrail:StopLogging.

AWS Config

While CloudTrail records actions, Config records state: the configuration of your resources over time, and whether that state complies with rules you define. Config rules can be AWS-managed ("every EBS volume must be encrypted," "MFA must be enabled on IAM users") or custom Lambda-backed logic. Non-compliant resources are flagged, and Config can auto-remediate — for example, triggering a Systems Manager runbook to re-enable Block Public Access on a bucket someone opened.

The exam contrast: "who changed it?" → CloudTrail. "Is it configured correctly right now, and prove it over time?" → Config. Compliance auditing, configuration history, and drift detection are Config's domain. A question asking for "a timeline of configuration changes to a security group over the past six months" is Config, not CloudTrail.

End-of-Chapter Test

1. A company runs workloads in 30 AWS accounts under AWS Organizations. The security team must ensure that no user in any account — including account administrators — can disable CloudTrail logging. What is the most effective solution? A) Attach an IAM policy denying cloudtrail:StopLogging to every user in each account B) Create an SCP that denies cloudtrail:StopLogging and attach it to the organization root C) Enable MFA Delete on the CloudTrail S3 bucket D) Configure a Config rule that flags accounts where CloudTrail is disabled

2. A developer needs temporary access to read objects from an S3 bucket owned by a different AWS account. The bucket owner wants to grant this access without creating an IAM user for the developer. Which combination should the bucket owner use? A) An IAM group in the developer's account and a bucket ACL B) A cross-account IAM role with a trust policy allowing the developer's account, plus a bucket policy permitting the role C) A pre-signed URL generated by the bucket owner for each object D) An SCP that allows s3:GetObject across both accounts

3. An application stores database credentials that must be automatically rotated every 30 days. Which AWS service should be used? A) SSM Parameter Store with SecureString parameters B) AWS Secrets Manager C) AWS KMS with automatic key rotation D) An encrypted S3 bucket with versioning

4. A security audit requires a record of every KMS key usage including which identity performed each encrypt and decrypt operation. Which S3 encryption mode provides this audit trail? A) SSE-S3, because S3 logs all encryption operations to CloudTrail by default B) SSE-KMS, because each key usage generates a CloudTrail event C) SSE-C, because the customer controls the key material D) Client-side encryption, because keys never leave the customer network

5. A web application running behind an Application Load Balancer is experiencing SQL injection attempts. Which service should be deployed to block these Layer 7 attacks? A) AWS Shield Standard B) A network ACL with deny rules for the attacker IPs C) AWS WAF with the SQL injection managed rule group D) AWS Firewall Manager

6. A company wants traffic between its VPC and Amazon S3 to stay on the private AWS network without traversing the public internet, at no additional hourly cost. Which solution meets these requirements? A) An interface VPC endpoint for S3 B) A NAT gateway with a route to S3 C) A gateway VPC endpoint for S3 D) AWS PrivateLink with a Network Load Balancer

7. An organization needs to find all Amazon S3 buckets that contain unencrypted personally identifiable information (PII) across hundreds of buckets. Which service should they use? A) Amazon GuardDuty B) Amazon Macie C) Amazon Inspector D) AWS Security Hub

8. A developer reports that an application on an EC2 instance cannot reach the internet, but the security group allows all outbound traffic. The subnet's NACL allows inbound traffic on port 443 but has no outbound rules for ephemeral ports. What is the most likely cause? A) The security group is misconfigured because security groups are stateless B) The NACL is blocking return traffic because NACLs are stateless and require explicit outbound rules C) The instance needs an IAM role to access the internet D) The route table is missing a route to the NAT gateway, which NACLs cannot fix

9. A company must ensure that all new EBS volumes in a Region are encrypted at rest without relying on engineers to enable encryption manually. What should they do? A) Attach an IAM policy that denies ec2:RunInstances unless volumes are encrypted B) Enable EBS encryption by default for the Region C) Create a Config rule that encrypts unencrypted volumes automatically D) Use AWS Secrets Manager to store volume encryption keys

10. A third-party monitoring vendor needs read-only access to a company's AWS account. The company wants to prevent the confused deputy problem. What should the trust policy of the cross-account role include? A) An MFA condition requiring the vendor's users to authenticate with MFA B) A permission boundary limiting the vendor to read-only actions C) An external ID condition with a unique value shared only with the legitimate vendor D) A resource-based policy on every resource the vendor will read

11. Which service provides a centralized view of security findings from GuardDuty, Inspector, and Macie, normalized against compliance frameworks such as CIS benchmarks? A) AWS CloudTrail B) AWS Config C) AWS Security Hub D) IAM Access Analyzer

12. A company needs free, automatically renewing TLS certificates for its public Application Load Balancer. Which solution should they choose? A) AWS Certificate Manager with a public certificate B) AWS KMS to generate a self-signed certificate C) IAM server certificates uploaded manually D) AWS Secrets Manager to store a third-party certificate

Answer Key

1. B — Only an SCP can restrict even account administrators and root users; IAM policies cannot override administrator permissions, and Config only detects drift rather than preventing it. 2. B — Cross-account access requires a role in the bucket owner's account with a trust policy for the other account, plus a bucket policy (resource-based policy) granting the role access. 3. B — Secrets Manager provides built-in automatic rotation of database credentials; Parameter Store SecureString has no native rotation capability. 4. B — Every KMS API call is logged to CloudTrail with the calling identity, giving a full audit trail; SSE-S3 provides no per-key usage logging. 5. C — AWS WAF inspects Layer 7 web traffic and its managed rule groups specifically cover SQL injection; Shield handles DDoS and NACLs cannot inspect request content. 6. C — A gateway endpoint for S3 is free and keeps traffic on the private AWS network via route table entries; interface endpoints incur hourly charges. 7. B — Macie uses machine learning to discover PII and sensitive data in S3 buckets; GuardDuty detects threats, Inspector finds vulnerabilities, and Security Hub only aggregates findings. 8. B — NACLs are stateless, so return traffic on ephemeral ports must be explicitly allowed outbound; security groups are stateful and would allow the response automatically. 9. B — Enabling EBS encryption by default guarantees every new volume and snapshot is encrypted with no per-instance action required. 10. C — The external ID condition ensures only the legitimate third party that knows the secret value can assume the role, preventing the confused deputy attack. 11. C — Security Hub aggregates findings from multiple detective services into a single normalized dashboard with compliance scoring; it generates no findings itself. 12. A — ACM provisions free public TLS certificates that renew automatically when used with integrated services like an ALB.