Domain 2: Security

AWS Certified Developer – Associate (DVA-C02)

Domain 2: Security

Exam Code: DVA-C02 | Level: Associate
Domain Weight: 26% | Total Domains: 4 | Passing Score: 720/1000

---

Table of Contents

1. AWS IAM — Identity & Access Management
   • 1.1 Core Components & Policy Structure
   • 1.2 Policy Evaluation Logic
   • 1.3 IAM Roles & iam:PassRole
   • 1.4 Permissions Boundary & Condition Keys
   • 1.5 Credential Chain & Audit Tools
2. AWS STS — Security Token Service
   • 2.1 Key APIs & Cross-Account Access
3. AWS KMS — Key Management Service
   • 3.1 Key Types & Algorithms
   • 3.2 KMS APIs & Envelope Encryption
   • 3.3 Key Policies, Quotas & CloudHSM
4. Amazon S3 Security
   • 4.1 Access Control Layers
   • 4.2 S3 Encryption Methods
   • 4.3 MFA Delete, Pre-signed URLs & CORS
5. Amazon Cognito Security
   • 5.1 User Pools vs Identity Pools
   • 5.2 Fine-Grained Access & Lambda Triggers
6. API Gateway Security
   • 6.1 Authorizer Types
   • 6.2 Resource Policies & Usage Plans
7. Secrets Manager & SSM Parameter Store
8. Encryption at Rest & In Transit
9. Network Security
   • 9.1 Security Groups vs NACLs
   • 9.2 VPC Endpoints & AWS WAF
10. AWS CloudTrail & Audit
    • 10.1 Event Types & Retention
    • 10.2 CloudTrail vs CloudWatch vs X-Ray
11. Exam Tips & Quick Reference

---

1. AWS IAM — Identity & Access Management

IAM is the security centre of every AWS account. It controls who can authenticate (who you are) and what they are authorized to do (what you can access). Every AWS API call is authorized through IAM.

1.1 Core Components & Policy Structure

Key structural rules:

• Groups contain users only — you cannot nest groups inside groups.
• A user can belong to multiple groups simultaneously.
• Roles are assumed temporarily via STS — they issue short-lived credentials.

IAM Policy JSON Structure:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowS3Read",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:root"
      },
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Resource": ["arn:aws:s3:::my-bucket/*"],
      "Condition": {
        "StringEquals": { "aws:RequestedRegion": "us-east-1" }
      }
    }
  ]
}

Critical: The Principal field only appears in resource-based policies (S3 bucket policies, SQS queue policies, Lambda resource policies, KMS key policies). Identity-based policies attached to users, groups, and roles do NOT include a Principal.

Policy Types:

1.2 Policy Evaluation Logic

┌─────────────────────────────────────────────────────────────────────┐
│                    IAM Policy Evaluation Flow                        │
│                                                                       │
│  Start: Default DENY (implicit)                                       │
│                                                                       │
│  Evaluate ALL applicable policies:                                    │
│  • Identity-based policies (user, group, role)                        │
│  • Resource-based policies (S3 bucket policy, etc.)                   │
│  • Permissions boundaries                                             │
│  • SCPs (Service Control Policies, if using AWS Organizations)        │
│                                                                       │
│  ┌────────────────────────────────────────┐                           │
│  │  Any EXPLICIT DENY found?              │──► YES ──► Final: DENY    │
│  └────────────────────────────────────────┘                           │
│                       │ NO                                            │
│                       ▼                                               │
│  ┌────────────────────────────────────────┐                           │
│  │  Any EXPLICIT ALLOW found?             │──► YES ──► Final: ALLOW   │
│  └────────────────────────────────────────┘                           │
│                       │ NO                                            │
│                       ▼                                               │
│                  Final: DENY (implicit)                               │
└─────────────────────────────────────────────────────────────────────┘

Critical: An explicit DENY always wins over any ALLOW, regardless of which policy contains it. There is no way to override an explicit DENY.

Union evaluation — IAM + S3 Bucket Policy:

1.3 IAM Roles & iam:PassRole

Role components:

• Trust Policy — defines who can assume this role (the principal: a service, another account, a user).
• Permission Policy — defines what the role can do once assumed.

// Trust Policy example — allows EC2 to assume this role
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "Service": "ec2.amazonaws.com" },
    "Action": "sts:AssumeRole"
  }]
}

Common service role assignments:

iam:PassRole — The gatekeeper permission:

When you assign an IAM role to an AWS service (launch EC2 with a role, create a Lambda function with an execution role), you are "passing" that role to the service. AWS requires you to have explicit permission to do this.

// Policy granting a developer the ability to pass a specific role to EC2
{
  "Effect": "Allow",
  "Action": ["iam:PassRole", "iam:GetRole"],
  "Resource": "arn:aws:iam::123456789012:role/EC2AppRole"
}

Critical Exam Trap: Having ec2:RunInstances permission does NOT grant the ability to launch an EC2 instance with an IAM role. iam:PassRole is a separate, required permission. Missing it results in Access Denied even when the user has full EC2 permissions.

1.4 Permissions Boundary & Condition Keys

Permissions Boundary:
A managed policy that acts as an upper limit on what permissions an identity policy can grant. The effective permissions are the intersection of the boundary and the identity policy.

Permissions Boundary: Allow S3, EC2
Identity Policy:      Allow S3, DynamoDB
────────────────────────────────────────
Effective Permissions: Allow S3 only

Key Rule: A boundary does not GRANT permissions.
          It only LIMITS what identity policies can grant.

Use case: allow developers to create IAM roles for their services, but prevent them from creating roles with permissions beyond what they themselves have (preventing privilege escalation).

Common IAM Condition Keys:

// Require MFA for sensitive actions
"Condition": { "Bool": { "aws:MultiFactorAuthPresent": "true" } }

// Restrict access to a specific AWS region
"Condition": { "StringEquals": { "aws:RequestedRegion": "us-east-1" } }

// Require HTTPS (deny non-secure transport)
"Condition": { "Bool": { "aws:SecureTransport": "true" } }

// S3: restrict access to each user's own prefix
"Condition": { "StringLike": { "s3:prefix": ["home/${aws:username}/*"] } }

// DynamoDB: restrict access to each user's own rows
"Condition": {
  "ForAllValues:StringEquals": {
    "dynamodb:LeadingKeys": ["${aws:userid}"]
  }
}

// Restrict by resource tag value
"Condition": { "StringEquals": { "aws:ResourceTag/Environment": "Production" } }

1.5 Credential Chain & Audit Tools

AWS CLI and SDK Credential Resolution Order (first match wins):

1. Command-line options  (e.g., --profile, --region flags)
2. Environment variables  (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN)
3. AWS credentials file   (~/.aws/credentials)
4. AWS config file        (~/.aws/config)
5. ECS container credentials  (for tasks running on ECS)
6. EC2 Instance Profile   (IMDS at 169.254.169.254) ← lowest priority

Critical Exam Trap: If environment variables are set on an EC2 instance, they override the Instance Profile — even though the Instance Profile is the recommended and more secure approach. Always remove hardcoded environment variable credentials from EC2 and rely on the Instance Profile instead.

IAM Audit Tools:

IAM Best Practices:

• Never use the root account for daily operations. Lock it down and enable MFA.
• Enable MFA on all privileged users.
• One physical person = one IAM user. Never share credentials.
• Assign permissions to groups, not directly to individual users.
• Use IAM roles for all service-to-service access. Never hardcode access keys.
• Rotate access keys regularly. Use the Credentials Report to find old keys.
• Apply least privilege — grant only what is needed and nothing more.

---

2. AWS STS — Security Token Service

STS issues temporary, limited-privilege security credentials for IAM users, federated users, or AWS services assuming roles.

2.1 Key APIs & Cross-Account Access

Cross-Account Access Flow:

┌─────────────────────────────────────────────────────────────────────┐
│                   Cross-Account Role Assumption                      │
│                                                                       │
│  Account A (Dev)                    Account B (Prod)                 │
│  ┌──────────────┐                   ┌───────────────────────────┐    │
│  │  IAM User    │──sts:AssumeRole──►│  IAM Role "ReadProdData"  │    │
│  │  "Alice"     │                   │  Trust: Account A allowed │    │
│  └──────────────┘                   └──────────────┬────────────┘    │
│        │                                           │                 │
│        │◄─────── Temporary credentials ───────────┘                 │
│        │         (AccessKey, SecretKey, SessionToken)                │
│        │                                                             │
│        └──────────────────────────────────────────────────────────► │
│                   Access Account B resources using temp creds        │
└─────────────────────────────────────────────────────────────────────┘

Setup requirements for cross-account access:

1. Account B: Create an IAM Role with a Trust Policy that allows Account A's user or role to assume it.
2. Account A: Attach an IAM Policy to the user/role that allows sts:AssumeRole on Account B's role ARN.

Temporary credential duration:

• Minimum: 15 minutes.
• Maximum: 1 hour for most role assumptions.
• Maximum: 12 hours for console federation sessions.

MFA with CLI:

# Step 1: Get temporary credentials using your MFA device
aws sts get-session-token \
  --serial-number arn:aws:iam::123456789012:mfa/alice \
  --token-code 123456 \
  --duration-seconds 3600

# Step 2: Export the returned credentials as environment variables
export AWS_ACCESS_KEY_ID=ASIA...
export AWS_SECRET_ACCESS_KEY=...
export AWS_SESSION_TOKEN=...

# Now run commands that require MFA — credentials contain the MFA assertion

---

3. AWS KMS — Key Management Service

KMS is the central service for creating and managing cryptographic keys. All KMS API calls are logged in CloudTrail, providing a complete audit trail of key usage.

3.1 Key Types & Algorithms

By Ownership:

Critical: Imported key material does NOT support automatic rotation. To rotate, you must create a new CMK, import new material, and update the alias to point to the new key.

By Algorithm:

3.2 KMS APIs & Envelope Encryption

Core KMS APIs:

Critical: The Encrypt API has a hard 4 KB limit. For anything larger — files, documents, database records — you must use Envelope Encryption via GenerateDataKey.

Envelope Encryption:

┌─────────────────────────────────────────────────────────────────────┐
│                    Envelope Encryption Flow                          │
│                                                                       │
│  ENCRYPTION:                                                          │
│  1. Call GenerateDataKey (CMK ARN)                                    │
│     → Returns: Plaintext DEK  +  Encrypted DEK                       │
│  2. Use Plaintext DEK to encrypt your large file locally (AES-256)   │
│  3. Immediately discard Plaintext DEK from memory                     │
│  4. Store: [ Encrypted File ] + [ Encrypted DEK ] together           │
│                                                                       │
│  DECRYPTION:                                                          │
│  1. Retrieve: [ Encrypted File ] + [ Encrypted DEK ]                  │
│  2. Call KMS Decrypt with the Encrypted DEK                           │
│     → Returns: Plaintext DEK                                          │
│  3. Use Plaintext DEK to decrypt the file locally                     │
│  4. Immediately discard Plaintext DEK from memory                     │
│                                                                       │
│  Key insight: The CMK never leaves KMS. Only the small Encrypted DEK │
│  travels with your data. KMS never sees your raw file content.        │
└─────────────────────────────────────────────────────────────────────┘

Exam Rule: Any question about encrypting data larger than 4 KB using KMS → the answer involves GenerateDataKey and Envelope Encryption.

3.3 Key Policies, Quotas & CloudHSM

Key Policies:

• Every CMK must have a key policy. Without one, no one — not even the root account — can use the key.
• The default key policy grants the root account full control, allowing IAM policies to then delegate access.
• A custom key policy specifies exactly which principals can administer and use the key.
• Cross-account KMS access requires: (1) key policy allows the other account, AND (2) IAM policy in the other account allows the action.

KMS Quotas (causes ThrottlingException):

When throttled: implement exponential backoff. For S3 workloads using SSE-KMS at high volume, enable S3 Bucket Keys to reduce KMS API calls by approximately 99%.

KMS vs CloudHSM:

---

4. Amazon S3 Security

4.1 Access Control Layers

S3 has multiple overlapping access control mechanisms. Understanding how they interact — especially with Block Public Access — is critical for the exam.

Critical: Block Public Access settings override bucket policies. If Block Public Access is enabled on a bucket, a bucket policy granting public access has no effect.

Common Bucket Policy Patterns:

// Force HTTPS — deny all non-secure transport
{
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:*",
  "Resource": ["arn:aws:s3:::my-bucket", "arn:aws:s3:::my-bucket/*"],
  "Condition": { "Bool": { "aws:SecureTransport": "false" } }
}

// Force SSE-KMS encryption on all uploads
{
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:PutObject",
  "Resource": "arn:aws:s3:::my-bucket/*",
  "Condition": {
    "StringNotEquals": { "s3:x-amz-server-side-encryption": "aws:kms" }
  }
}

// Grant cross-account read access
{
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::ACCOUNT-B:root" },
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::my-bucket/*"
}

4.2 S3 Encryption Methods

Exam Rule: If the question requires an audit trail of who used which key and when → SSE-KMS.
If the question says the customer must own and manage the key entirely (not in KMS) → SSE-C (HTTPS mandatory) or Client-side encryption.

SSE-KMS at high volume:
Every SSE-KMS upload calls GenerateDataKey. Every download calls Decrypt. At tens of thousands of requests per second, this hits KMS rate limits. Solution: enable S3 Bucket Keys to generate a bucket-level data key that encrypts individual object keys locally — reduces KMS API calls by ~99%.

Critical: An S3 PutObject with SSE-KMS returns Access Denied when the uploading user or role lacks kms:GenerateDataKey permission on the CMK. The S3 permission alone is insufficient.

4.3 MFA Delete, Pre-signed URLs & CORS

MFA Delete:

• Requires an MFA code to permanently delete an object version or suspend versioning.
• Can only be enabled or disabled by the bucket owner using the root account credentials.
• Versioning must be enabled before MFA Delete can be configured.

Pre-signed URLs:

CORS (Cross-Origin Resource Sharing):
Configured on the target bucket — the bucket that holds the assets being loaded by the browser from a different origin.

[{
  "AllowedOrigins": ["https://www.example.com"],
  "AllowedMethods": ["GET", "PUT"],
  "AllowedHeaders": ["*"],
  "MaxAgeSeconds": 3000
}]

Exam Trap: A 403 error on a cross-origin S3 request almost always means the CORS configuration is missing or incorrect on the target bucket — not an IAM permission issue.

---

5. Amazon Cognito Security

Cognito provides authentication and authorization for web and mobile applications. Its two components serve completely different purposes and are commonly confused on the exam.

5.1 User Pools vs Identity Pools

┌─────────────────────────────────────────────────────────────────────┐
│                    Cognito — Two Services                            │
│                                                                       │
│  COGNITO USER POOL (CUP)          COGNITO IDENTITY POOL (CIP)        │
│  ─────────────────────────        ──────────────────────────────     │
│  AuthN — Who are you?             AuthZ — What can you access?       │
│                                                                       │
│  Input:  Username + Password      Input:  A valid identity token     │
│          (or social/SAML token)           (from CUP, Google, SAML)  │
│                                                                       │
│  Output: JWT Tokens               Output: Temporary AWS credentials  │
│          • ID Token                        via STS AssumeRole        │
│          • Access Token                    (AccessKey + SecretKey    │
│          • Refresh Token                    + SessionToken)          │
│                                                                       │
│  Use for: Your APIs, ALB          Use for: S3, DynamoDB, Kinesis     │
│           API Gateway                      direct SDK calls          │
│                                                                       │
│  Guest access: No                 Guest access: Yes (unauthenticated)│
└─────────────────────────────────────────────────────────────────────┘

Critical Exam Rule: A JWT token from a User Pool grants access to your API (via API Gateway Cognito Authorizer). It does NOT grant access to AWS services like S3 or DynamoDB directly. To call AWS services directly from a mobile app, you need Identity Pools to exchange the JWT for temporary AWS credentials.

Cognito User Pools — Key Features:

• Handles sign-up, sign-in, MFA, email/phone verification, and password reset.
• Federates with: Facebook, Google, Amazon, Apple, SAML 2.0 IdPs, and OIDC providers.
• MFA options: TOTP (authenticator apps) or SMS OTP.
• Adaptive authentication: assigns a risk score to each sign-in attempt and can require MFA when risk is high.

Cognito Identity Pools:

• Assigns each user a unique Identity ID regardless of which identity provider they used.
• Two IAM roles: one for authenticated users, one for unauthenticated (guest) users.
• Guest access: provide limited AWS access without any login required.

5.2 Fine-Grained Access & Lambda Triggers

Per-user resource isolation using IAM policy variables:

// Restrict each Cognito user to their own S3 folder
{
  "Effect": "Allow",
  "Action": ["s3:GetObject", "s3:PutObject"],
  "Resource": "arn:aws:s3:::my-bucket/${cognito-identity.amazonaws.com:sub}/*"
}

// Restrict each Cognito user to their own DynamoDB rows (LeadingKeys)
{
  "Effect": "Allow",
  "Action": ["dynamodb:GetItem", "dynamodb:PutItem"],
  "Resource": "arn:aws:dynamodb:us-east-1:*:table/UserData",
  "Condition": {
    "ForAllValues:StringEquals": {
      "dynamodb:LeadingKeys": ["${cognito-identity.amazonaws.com:sub}"]
    }
  }
}

Lambda Triggers (User Pools):

Critical: The Cognito Hosted UI custom domain requires an ACM certificate in us-east-1, regardless of the User Pool's region. This is a commonly tested trap.

---

6. API Gateway Security

6.1 Authorizer Types

API Gateway supports three authorizer mechanisms. Choosing the right one is a frequent exam scenario.

┌─────────────────────────────────────────────────────────────────────┐
│               API Gateway Authorizer Decision Tree                   │
│                                                                       │
│  Caller is an AWS service/EC2/Lambda using AWS credentials?          │
│  └──► YES: IAM Authorization + SigV4 signing                         │
│                                                                       │
│  Caller uses a 3rd-party JWT, OAuth, or custom token?                │
│  └──► YES: Lambda Authorizer (custom logic in your Lambda function)  │
│                                                                       │
│  Caller is a mobile/web app user authenticated via Cognito?          │
│  └──► YES: Cognito User Pool Authorizer (API GW validates JWT)       │
└─────────────────────────────────────────────────────────────────────┘

Exam Trap: The Cognito Authorizer handles authentication only — confirming the user is who they claim to be. Authorization (what the user can do) must be enforced in your backend application code. API Gateway does not enforce method-level permissions based on Cognito user attributes.

6.2 Resource Policies & Usage Plans

Resource Policies:
JSON policies attached directly to an API Gateway REST API. Used to:

• Restrict API access to specific AWS accounts.
• Restrict access to specific source IP ranges or CIDR blocks.
• Allow access only from specific VPCs or VPC Endpoints (for private APIs).

API Keys and Usage Plans:

Step-by-step setup (exam tests this order):

1. Create the API → configure methods to require an API key → deploy to a stage
2. Generate or import API keys
3. Create a Usage Plan (define throttle rate and monthly request quota)
4. Associate the API stage with the Usage Plan
5. Associate API Keys with the Usage Plan (via CreateUsagePlanKey API)

If step 5 is skipped → API key returns 403 Forbidden

Exam Trap: Creating an API key alone does nothing. The key must be associated with a Usage Plan via CreateUsagePlanKey. A newly created key returns 403 until this association is made.

---

7. Secrets Manager & SSM Parameter Store

Two services for storing secrets and configuration. Choosing between them is a common exam scenario.

SSM Parameter Store types:

# Store a plaintext value
aws ssm put-parameter --name "/myapp/config/db-host" --value "db.example.com" --type String

# Store an encrypted secret (KMS-encrypted)
aws ssm put-parameter --name "/myapp/secrets/db-password" --value "MySecureP@ss" --type SecureString

# Retrieve and decrypt a SecureString
aws ssm get-parameter --name "/myapp/secrets/db-password" --with-decryption

Reference in buildspec.yml (CodeBuild):

env:
  parameter-store:
    DB_PASSWORD: /myapp/secrets/db-password
  secrets-manager:
    API_KEY: arn:aws:secretsmanager:us-east-1:123:secret:my-api-key

Best Practice: Never store secrets as plaintext in env.variables in buildspec.yml. Always use parameter-store or secrets-manager sections.

---

8. Encryption at Rest & In Transit

Encryption at Rest — Service Summary

Critical: CloudWatch Logs KMS encryption cannot be configured from the AWS Management Console. You must use the AWS CLI command aws logs associate-kms-key for existing log groups, or specify the KMS key at creation time.

# Encrypt an existing CloudWatch Logs log group (CLI only)
aws logs associate-kms-key \
  --log-group-name /aws/lambda/my-function \
  --kms-key-id arn:aws:kms:us-east-1:123456789012:key/abc-123

Encryption in Transit

• Force HTTPS on S3: Use a bucket policy that denies requests where aws:SecureTransport is false.
• SSE-C requires HTTPS: The encryption key is included in the HTTP request header — using plain HTTP would expose the key in transit.
• API Gateway: Always serves HTTPS. HTTP is not available.
• CloudFront — Viewer Protocol Policy: Set to HTTPS Only or Redirect HTTP to HTTPS to enforce HTTPS between clients and CloudFront.
• CloudFront — Origin Protocol Policy: Set to HTTPS Only to enforce HTTPS between CloudFront and the S3 or ALB origin.

---

9. Network Security

9.1 Security Groups vs NACLs

Exam Rule: Connection Timeout when connecting to EC2 → Security Group is blocking the traffic. Connection Refused → traffic reached EC2 but the application is not running or listening on the expected port.

9.2 VPC Endpoints & AWS WAF

VPC Endpoints — two types:

Use case: Lambda or ECS in a VPC needs to access S3 or DynamoDB without traversing the internet. Add a Gateway Endpoint — no NAT Gateway required. This is cheaper and more secure than routing through a NAT Gateway.

AWS WAF (Web Application Firewall):

• Attach to: ALB, API Gateway REST API, CloudFront.
• Protects against: SQL injection, XSS, HTTP floods, bad bots, geographic restrictions.
• Rules match on: IP addresses, HTTP headers, URI strings, request body content.
• Uses Web ACLs containing rules and rule groups.

VPC Flow Logs:

• Capture metadata about network traffic flowing through ENIs, subnets, or VPCs.
• Records include: source IP, destination IP, port, protocol, bytes transferred, accept/reject status.
• Does NOT capture application-layer content — it is network metadata only.
• Destination: CloudWatch Logs or S3.

---

10. AWS CloudTrail & Audit

10.1 Event Types & Retention

CloudTrail records all API calls made to your AWS account, regardless of whether the call came from the Console, CLI, SDK, or another AWS service.

Retention:

• CloudTrail stores events for 90 days in the CloudTrail console.
• For longer retention: configure a Trail to deliver events to an S3 bucket, then analyze with Amazon Athena.

CloudTrail + EventBridge — Automated Response Pattern:

IAM user deletes a production DynamoDB table
  ──► CloudTrail records the DeleteTable API call
       ──► EventBridge rule matches on source: "aws.dynamodb" + action: "DeleteTable"
            ──► SNS topic sends alert to security team
            ──► Lambda function attempts automated remediation

10.2 CloudTrail vs CloudWatch vs X-Ray

---

11. Exam Tips & Quick Reference

Scenario-to-Answer Mapping

---

Common Traps

• iam:PassRole is separate from service permissions: Having full EC2 or Lambda permissions does not include the ability to assign an IAM role to those services. iam:PassRole is a distinct permission that must be explicitly granted.
• Cognito User Pools produce JWTs, not AWS credentials: A JWT from a User Pool lets you call your own API. To call AWS services directly (S3, DynamoDB), exchange the JWT for temporary credentials via a Cognito Identity Pool.
• CloudWatch Logs KMS via CLI only: The AWS Management Console does not support associating a KMS key with a CloudWatch Logs log group. This must be done via the associate-kms-key CLI command.
• SSE-C requires HTTPS: When using server-side encryption with a customer-provided key, the key is included in the request header. Using plain HTTP would expose the key in transit. HTTPS is mandatory.
• S3 Bucket Key reduces CloudTrail events too: When S3 Bucket Keys are enabled, KMS generates one data key per bucket per time period instead of one per object. This reduces both KMS API calls and the number of CloudTrail log entries for KMS key usage.
• Block Public Access overrides bucket policies: A bucket policy granting public access is irrelevant if Block Public Access is enabled. The Block Public Access setting wins.
• Permissions Boundary does not grant permissions: A boundary defines the maximum possible permissions. An identity still needs an explicit Allow in their identity policy. Boundary alone = no access.

---

Key Terms — Domain 2

---

End of Domain 2: Security. Continue to Domain 3: Deployment →