75 of 429 questions · Page 3/6 · Dva Security topic · Answers revealed
Match each AWS tool or feature to its description.
Drag a concept onto its matching description — or click a concept then click the description.
Infrastructure as Code
PaaS for web apps
Automated code deployment
Distributed tracing
Key management encryption
Why these pairings
These tools are commonly used for deployment, monitoring, and security.
A developer is creating an IAM policy for an EC2 instance to allow it to read from an S3 bucket. Which of the following are required? (Choose TWO.)
The IAM role provides the permissions.
Why this answer
Option A is correct because an IAM role must be created with the necessary permissions. Option C is correct because the role must be attached to the EC2 instance. Option B is wrong because S3 bucket policy is optional if using an IAM role; it's needed for cross-account.
Option D is wrong because KMS is not required. Option E is wrong because instance profile is not the same as role attachment.
A developer is creating an IAM policy for a Lambda function that needs to read from an SQS queue and write to a DynamoDB table. Which THREE permissions are required? (Select THREE.)
Required to delete messages after processing.
Why this answer
A is correct because the Lambda function must delete messages from the SQS queue after processing them to prevent them from being reprocessed. The sqs:DeleteMessage permission is required to call the DeleteMessage API, which removes the message from the queue using its receipt handle. Without this permission, the function would successfully receive and process the message but fail to delete it, causing the message to become visible again after the visibility timeout expires.
Exam trap
The trap here is that candidates often confuse the permissions needed for a Lambda function acting as a consumer (ReceiveMessage and DeleteMessage) with those needed for a producer (SendMessage), or they mistakenly think GetItem is required for writing to DynamoDB when PutItem is the correct write operation.
A developer runs the above command and gets the output shown. What is the developer verifying?
The command get-object-attributes returns object attributes.
Why this answer
Option A is correct because the command retrieves attributes of an object, including its size and ETag. Option B is wrong because the command does not check encryption. Option C is wrong because version ID is not requested.
Option D is wrong because the command does not test permissions; it returns attributes successfully.
A developer is building a mobile application that uses Amazon Cognito for user authentication. After a user signs in, the application needs to access an Amazon DynamoDB table. The developer has set up an identity pool with an authenticated role. The IAM role attached to the authenticated identity has a policy allowing the required DynamoDB actions. However, users report that they cannot perform DynamoDB operations. What is the MOST likely cause of this issue?
The trust policy of the IAM role must grant the Cognito Identity service principal the sts:AssumeRole permission. Without it, Cognito cannot issue credentials, resulting in denied actions.
Why this answer
The most likely cause is that the IAM role's trust policy does not include a statement allowing Amazon Cognito (specifically the `cognito-identity.amazonaws.com` service principal) to assume the role. Even if the identity pool is configured to use the authenticated role and the role's permissions policy grants DynamoDB actions, Cognito must be able to assume the role via AWS Security Token Service (STS) `AssumeRoleWithWebIdentity`. Without the correct trust relationship, Cognito cannot obtain temporary credentials for the user, so all DynamoDB operations fail.
Exam trap
The trap here is that candidates often focus on the permissions policy (allowing DynamoDB actions) and overlook the trust policy, which is a separate and critical requirement for Cognito to assume the role and generate credentials.
How to eliminate wrong answers
Option A is wrong because if the identity pool were not configured to use the authenticated role, the developer would not have been able to set it up in the first place; the configuration is a prerequisite that is explicitly stated as done. Option B is wrong because the identity ID is used to identify the user within the identity pool, but passing an incorrect identity ID would cause authentication failures or mismatched credentials, not a permissions issue on DynamoDB after sign-in; the core problem is the lack of a trust policy allowing role assumption. Option D is wrong because KMS key encryption on the DynamoDB table would only cause access failures if the IAM role lacked `kms:Decrypt` permissions or the key policy denied access, but the question states the role's policy allows the required DynamoDB actions, and KMS key mismatch would produce a different error (AccessDeniedException for KMS), not a generic inability to perform DynamoDB operations.
A developer needs to allow an IAM user to manage only their own access keys (create, list, update, delete). Which IAM policy statement achieves this?
Restricts to own user.
Why this answer
Option A is correct because it uses the `iam:*AccessKey*` wildcard action to cover all access key management operations (create, list, update, delete) and restricts the resource to `arn:aws:iam::*:user/${aws:username}`. The `${aws:username}` policy variable dynamically resolves to the IAM user's own username, ensuring that each user can only manage their own access keys. This follows the principle of least privilege by scoping permissions to the user's own resource.
Exam trap
The trap here is that candidates often choose Option C (resource `*`) thinking it grants access to all users' keys, but they overlook that the wildcard resource would allow a user to manage other users' keys, violating the 'only their own' requirement.
How to eliminate wrong answers
Option B is wrong because it hardcodes the username 'JohnDoe', which would only allow that specific user to manage their own access keys, not any IAM user as required by the question. Option C is wrong because the resource `*` grants access to all IAM users' access keys, violating the requirement that each user manages only their own keys. Option D is wrong because it only includes read-only actions (`iam:ListAccessKeys` and `iam:GetAccessKeyLastUsed`) and omits the create, update, and delete actions needed to fully manage access keys.
A company is developing a web application that runs on Amazon EC2 instances. The application needs to access an Amazon DynamoDB table to store and retrieve data. The security team requires that no IAM users or roles should be used; instead, the application must use temporary credentials that are automatically rotated. Which approach should the developer use to securely grant access to DynamoDB?
This is the recommended approach. The IAM role provides temporary credentials that are automatically rotated by AWS. The AWS SDK obtains credentials from the EC2 instance metadata service (IMDS). No long-term credentials are stored on the instance.
Why this answer
Option B is correct because it uses an IAM role attached to the EC2 instance via an instance profile, which allows the AWS SDK to automatically retrieve temporary credentials from the EC2 instance metadata service (IMDS). These credentials are rotated automatically by AWS, satisfying the security team's requirement for no long-lived IAM users or roles and ensuring secure, temporary access to DynamoDB.
Exam trap
The trap here is that candidates may confuse pre-signed URLs (which only work for S3) with DynamoDB access, or assume that storing keys in Secrets Manager satisfies the 'temporary credentials' requirement when it still relies on long-lived IAM users.
How to eliminate wrong answers
Option A is wrong because it creates an IAM user with long-lived access keys, which violates the requirement for temporary credentials that are automatically rotated; storing keys in Secrets Manager still uses static credentials. Option C is wrong because pre-signed URLs are designed for S3 object access, not for DynamoDB operations, and DynamoDB does not support pre-signed URLs. Option D is wrong because embedding a long-lived API token in application code is insecure and does not provide automatic rotation, directly contradicting the security team's requirement.
A company wants to store database credentials securely and rotate them automatically on a schedule. The credentials are used by an AWS Lambda function to access an Amazon RDS instance. Which AWS service should the developer use to meet these requirements?
Secrets Manager automatically rotates credentials for RDS and other services, meeting the requirements.
Why this answer
AWS Secrets Manager is the correct choice because it is specifically designed to securely store, retrieve, and automatically rotate database credentials on a schedule. It natively supports automatic rotation for Amazon RDS databases (including MySQL, PostgreSQL, Oracle, SQL Server, and MariaDB) by integrating with Lambda to update the credentials in both Secrets Manager and the RDS instance. This meets the requirement for both secure storage and scheduled rotation without custom infrastructure.
Exam trap
The trap here is that candidates often confuse AWS Systems Manager Parameter Store (which can store secrets but lacks native rotation) with Secrets Manager, leading them to choose Parameter Store for its lower cost, but the requirement for automatic rotation disqualifies it.
How to eliminate wrong answers
Option B is wrong because AWS Systems Manager Parameter Store does not support automatic rotation of secrets; it requires custom solutions or integration with Secrets Manager for rotation. Option C is wrong because AWS KMS is a key management service for encryption keys, not for storing or rotating secrets like database credentials. Option D is wrong because AWS Certificate Manager (ACM) is used for managing SSL/TLS certificates, not for database credentials or rotation.
A developer in Account A has an Amazon S3 bucket that contains sensitive data. The developer wants to grant an IAM user in Account B read-only access to objects in the bucket. The developer has added a bucket policy in Account A that grants s3:GetObject access to the IAM user's ARN. However, the IAM user in Account B still receives Access Denied errors. What additional configuration is required?
The IAM user must have explicit permission via an IAM policy to access the S3 bucket. The bucket policy alone is not sufficient; the user's account must also allow the action.
Why this answer
Option A is correct because cross-account access to S3 requires both a bucket policy in the source account (Account A) granting the necessary permissions to the target IAM user, and an IAM identity-based policy in the target account (Account B) that explicitly allows the same action (s3:GetObject) on the bucket's ARN. Without the IAM policy in Account B, the user lacks the authorization to initiate the request, even though the bucket policy permits it. This dual-permission model is a fundamental security requirement for cross-account S3 access.
Exam trap
The trap here is that candidates often assume a bucket policy alone is sufficient for cross-account access, overlooking the mandatory IAM policy in the target account that must explicitly allow the action.
How to eliminate wrong answers
Option B is wrong because creating an S3 access point does not bypass the need for an IAM policy in Account B; access points still require both the bucket policy and the user's IAM policy to grant cross-account permissions. Option C is wrong because granting access to the entire AWS account B instead of the specific user would allow all principals in Account B (including unintended users) to access the bucket, which violates the principle of least privilege and does not resolve the missing IAM policy issue. Option D is wrong because S3 object ownership and bucket ACLs are legacy mechanisms that do not apply to cross-account access when a bucket policy is already in use; ACLs are disabled by default for new buckets and are not a substitute for the required IAM policy in Account B.
A developer needs to securely store database credentials for a Lambda function. Which AWS service should be used?
Secrets Manager is purpose-built for storing and rotating secrets.
Why this answer
AWS Secrets Manager is the correct service because it is purpose-built for securely storing, rotating, and managing database credentials and other secrets throughout their lifecycle. It integrates natively with Lambda via the AWS Secrets Manager API, allowing the function to retrieve credentials at runtime without hardcoding them, and supports automatic rotation using built-in or custom Lambda rotation functions. This makes it the ideal choice for securely handling database credentials in a serverless application.
Exam trap
The trap here is that candidates often confuse AWS KMS (which only manages encryption keys) with AWS Secrets Manager (which manages the full lifecycle of secrets), leading them to choose KMS because they think 'encryption' is the primary requirement, when in fact the question asks for secure storage and management of credentials, not just encryption.
How to eliminate wrong answers
Option B (AWS CloudHSM) is wrong because it provides dedicated hardware security modules (HSMs) for cryptographic key generation and storage, not for managing application secrets like database credentials; it lacks built-in secret rotation and retrieval APIs. Option C (AWS KMS) is wrong because it is a key management service for creating and controlling encryption keys used to encrypt data, not for storing or rotating secrets; while it can encrypt secrets stored elsewhere, it does not natively manage the secret lifecycle. Option D (Amazon DynamoDB) is wrong because it is a NoSQL database designed for high-performance, scalable data storage, not a secrets management service; storing credentials in DynamoDB would require manual encryption, rotation, and access control, increasing security risk and operational overhead.
A company uses an S3 bucket to store sensitive customer data. The bucket policy currently allows access to a specific IAM role used by an EC2 instance. A security audit reveals that the bucket is also accessible from an external AWS account. Which action should the security team take to restrict access to only the intended role?
This restricts access to the intended role.
Why this answer
Option D is correct because adding a condition in the bucket policy using the `aws:PrincipalArn` condition key allows you to restrict access exclusively to the specific IAM role ARN. This ensures that even if the bucket policy grants access to an external AWS account, only requests made by the designated IAM role (e.g., `arn:aws:iam::123456789012:role/EC2AppRole`) will be allowed, effectively blocking any other principals, including those from external accounts.
Exam trap
The trap here is that candidates often confuse IAM role trust policies with resource-based policies (like S3 bucket policies), thinking that modifying the trust policy will control access to the bucket, when in fact the bucket policy itself must explicitly restrict the principal.
How to eliminate wrong answers
Option A is wrong because disabling ACLs via S3 Object Ownership does not restrict access based on IAM roles or external accounts; it only controls whether ACLs are used to manage permissions, not the bucket policy or IAM policies. Option B is wrong because S3 Block Public Access only prevents public (anonymous or authenticated AWS users) access, but the external AWS account is a trusted AWS principal, not a public user, so Block Public Access would not block that access. Option C is wrong because the IAM role trust policy controls which entities can assume the role, not which principals can access the S3 bucket; the bucket policy must be modified to restrict access to the role.
A developer needs to allow an IAM user to temporarily access an AWS account for 12 hours. The developer must not create long-term credentials. What should the developer use?
STS provides temporary credentials with a configurable expiration, ideal for time-limited access.
Why this answer
IAM Security Token Service (STS) can generate temporary credentials with a custom expiration. By creating a role and allowing the user to assume it with a session duration of 12 hours, the requirement is met. Option A is wrong because IAM users have long-term credentials.
Option C is wrong because resource-based policies alone don't grant cross-account access with temporary credentials. Option D is wrong because Cognito is for end users.
Refer to the exhibit. A developer runs the AWS CLI command to decrypt a file using a KMS key alias 'my-key' and receives the error shown. The developer has an IAM policy that allows 'kms:Decrypt' on 'arn:aws:kms:us-east-1:123456789012:key/abcd1234-...'. Which additional step is required to resolve this error?
The key policy must explicitly grant the user permission to decrypt.
Why this answer
The error occurs because the KMS key policy does not grant the user permission to decrypt using the key. Even though the user has an IAM policy allowing 'kms:Decrypt' on the key, KMS requires that the key policy explicitly allow IAM user permissions (or grant the user direct access) for IAM policies to take effect. By adding the user's ARN to the key policy with 'kms:Decrypt', the key policy grants the necessary access, resolving the error.
Exam trap
The trap here is that candidates assume IAM policies alone are sufficient for KMS operations, but KMS requires the key policy to explicitly grant access to the user or enable IAM user permissions and then grant the action.
How to eliminate wrong answers
Option B is wrong because 'kms:DescribeKey' is not required for decryption; the error is about access denial, not missing key metadata. Option C is wrong because using the key ID instead of the alias would not resolve the access issue; the alias resolves to the same key, and the error is due to the key policy, not the identifier format. Option D is wrong because enabling IAM user permissions in the KMS key policy is a general setting that must be combined with an explicit grant of permissions to the user; simply enabling it without adding the user's ARN does not grant access.
A company stores sensitive data in an S3 bucket that must be encrypted at rest. The security team requires that all objects uploaded to the bucket are automatically encrypted using server-side encryption with AWS KMS (SSE-KMS). A developer uploads an object without specifying any encryption header. The upload succeeds, but the object is not encrypted. What is the most likely cause?
Without default encryption, objects uploaded without encryption headers remain unencrypted.
Why this answer
Option D is correct because S3 default encryption must be explicitly enabled on the bucket to enforce SSE-KMS when no encryption header is provided. Option A is wrong because bucket policies cannot enforce encryption headers retroactively; they can deny PutObject without encryption, but the upload would fail, not succeed unencrypted. Option B is wrong because the bucket policy does not block the upload.
Option C is wrong because the KMS key policy does not affect default encryption enforcement.
Refer to the exhibit. A developer runs an AWS CLI command on an EC2 instance and receives the error shown. The instance has an IAM role attached with the necessary permissions. What is the most likely cause of this error?
Missing credentials configuration.
Why this answer
The error indicates that the AWS CLI cannot find credentials. Even though the EC2 instance has an IAM role attached, the CLI will not automatically use instance profile credentials if environment variables (e.g., AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY) or a config file (e.g., ~/.aws/credentials) are present with different or invalid values. The CLI's credential provider chain checks environment variables first, then the config file, and only falls back to the instance metadata service (IMDS) if no other credentials are found.
Therefore, overriding settings are the most likely cause.
Exam trap
The trap here is that candidates assume the IAM role is automatically used by the CLI, but they overlook that environment variables or a local AWS credentials file can override the instance profile credentials, causing a 'Unable to locate credentials' error even when the role is correctly attached.
How to eliminate wrong answers
Option A is wrong because the AWS CLI is fully supported on EC2 instances and can run any command the instance's IAM role permits. Option C is wrong because the error message explicitly states 'Unable to locate credentials,' not a permissions error; if the role lacked permissions, the error would be 'AccessDenied' or similar. Option D is wrong because the question states the instance has an IAM role attached, so the role exists; the issue is that the CLI is not using it.
An application running on EC2 needs to access an S3 bucket. The developer has assigned an IAM role to the EC2 instance with a policy that allows s3:GetObject on the bucket. However, the application is still getting access denied errors. What should the developer check?
An explicit deny in the bucket policy overrides any allow from IAM.
Why this answer
Option B is correct because even if the IAM role attached to the EC2 instance allows s3:GetObject, an S3 bucket policy with an explicit deny statement that applies to that role will override the allow. IAM policy evaluation logic dictates that an explicit deny in any policy (resource-based or identity-based) takes precedence over any allow, resulting in access denied errors.
Exam trap
The trap here is that candidates assume an IAM role with an allow policy is sufficient, overlooking that S3 bucket policies can contain explicit deny statements that override the role's permissions.
How to eliminate wrong answers
Option A is wrong because S3 supports both HTTP and HTTPS, and using HTTP does not cause access denied errors; HTTPS is recommended for encryption in transit but not a requirement for authorization. Option C is wrong because the question does not mention S3 server-side encryption with KMS, and without a KMS key being used, KMS permissions are irrelevant to the access denied error. Option D is wrong because S3 buckets are global resources and do not reside in a VPC; EC2 instances can access S3 over the internet or via a VPC endpoint, but being in the same VPC is not a requirement for access.
A developer receives the above error when trying to launch an EC2 instance. What is the most likely cause?
The error explicitly states an explicit deny in a service control policy.
Why this answer
The error message explicitly mentions a service control policy (SCP) that denies the action. SCPs are applied at the organizational level. Option A is incorrect because IAM policy would not mention SCP.
Option C is incorrect because the error is about authorization, not service limits. Option D is incorrect because the error does not mention VPC.
A developer wants to allow an IAM user to rotate their own access keys. Which IAM policy action should be included?
Allows updating (activating/deactivating) keys.
Why this answer
Option B is correct because iam:UpdateAccessKey allows the user to update their own access keys. Option A is wrong because iam:CreateAccessKey alone does not allow rotation without update. Option C is wrong because iam:DeleteAccessKey deletes keys.
Option D is wrong because iam:GetAccessKeyLastUsed is read-only.
A developer is tasked with securing a legacy application that stores secrets in environment variables. Which THREE AWS services can be used to improve the security posture?
Used to encrypt secrets.
Why this answer
Secrets Manager, Parameter Store, and KMS can all help manage and encrypt secrets.
A company requires that all data in Amazon S3 be encrypted at rest using server-side encryption with a customer-managed KMS key. The developer needs to ensure that any object uploaded without the x-amz-server-side-encryption header set to aws:kms is denied. How can this be enforced?
Correct. A bucket policy can deny s3:PutObject when the required encryption header is absent, enforcing encryption on all uploads.
Why this answer
Option A is correct because an S3 bucket policy with a condition that denies s3:PutObject unless the `s3:x-amz-server-side-encryption` header equals `aws:kms` enforces server-side encryption with a customer-managed KMS key at the API level. This policy explicitly rejects any upload that does not include the required encryption header, ensuring compliance even if default encryption is bypassed or misconfigured.
Exam trap
The trap here is that candidates often confuse default encryption (which silently applies encryption but does not deny non-compliant uploads) with a bucket policy that actively denies requests, leading them to choose Option B as a simpler but ineffective solution.
How to eliminate wrong answers
Option B is wrong because configuring default encryption on the bucket with SSE-KMS only applies encryption to objects uploaded without an explicit encryption header; it does not deny uploads that omit the header, so objects can still be uploaded without the required `x-amz-server-side-encryption` header. Option C is wrong because S3 Object Lock is designed to prevent object deletion or overwrites for compliance or retention purposes, not to enforce encryption requirements during upload. Option D is wrong because CloudTrail trails only log API calls for auditing and monitoring; they cannot enforce or deny S3 PutObject operations based on encryption headers.
A developer needs to allow an EC2 instance to read from a DynamoDB table. Which is the best practice to grant permissions?
IAM roles are the secure way to grant permissions to EC2.
Why this answer
The best practice for granting an EC2 instance permissions to access DynamoDB is to create an IAM role with the required permissions and attach it to the instance. This eliminates the need to manage long-term credentials, as the instance automatically retrieves temporary security credentials from the instance metadata service (IMDS) via the AWS Security Token Service (STS). This approach follows the principle of least privilege and ensures credentials are rotated automatically.
Exam trap
The trap here is that candidates may confuse security groups (network-level access control) with IAM policies (identity-based access control) and incorrectly think adding a DynamoDB table ARN to a security group can grant data access, when in fact security groups only control network traffic and cannot authorize API calls to DynamoDB.
How to eliminate wrong answers
Option B is wrong because storing an IAM user access key in the application configuration introduces long-term static credentials that must be manually rotated, increasing the risk of exposure and violating AWS best practices for EC2. Option C is wrong because hardcoding AWS credentials in application code is a severe security risk, as the credentials can be exposed through version control, logs, or decompilation, and it also prevents automatic rotation. Option D is wrong because security groups are stateful firewalls that control network traffic at the instance level, not IAM permissions; they cannot grant access to DynamoDB, which operates over HTTPS and requires identity-based authentication.
A developer needs to grant temporary access to an Amazon S3 bucket for a user from a different AWS account. The developer wants to use the most secure method that does not require sharing long-term credentials. Which approach should the developer take?
This allows the external user to assume a role in the developer's account, obtaining temporary credentials. It does not require sharing long-term keys and provides fine-grained control.
Why this answer
Option C is correct because using cross-account IAM roles with AWS Security Token Service (STS) AssumeRole allows the external user to obtain temporary, limited-privilege credentials without sharing any long-term access keys. This approach follows the principle of least privilege and eliminates the risk of exposed static credentials, as the temporary credentials automatically expire after a configurable duration (default 1 hour, max 12 hours).
Exam trap
The trap here is that candidates often confuse S3 bucket policies with cross-account access, thinking a bucket policy alone can grant temporary credentials, when in fact bucket policies only authorize access based on the requester's existing (long-term) credentials and do not issue temporary tokens.
How to eliminate wrong answers
Option A is wrong because sharing IAM user access keys exposes long-term credentials that never expire, violating the requirement for temporary access and increasing the risk of credential leakage. Option B is wrong because an S3 bucket policy with a condition for an external account's IAM user still requires that external user to use their own long-term IAM credentials to sign requests, which does not grant temporary access and does not eliminate long-term credential sharing. Option D is wrong because S3 ACLs use canonical user IDs (the account's AWS-assigned identifier) and require the external user to authenticate with their own long-term credentials; ACLs also do not provide temporary credentials and are considered a legacy access control mechanism that is less secure and less flexible than IAM roles.
A developer is designing a serverless application using AWS Lambda and API Gateway. The application needs to authenticate users via a third-party identity provider (IdP). Which TWO services can be used to manage user authentication?
Can federate with third-party IdPs.
Why this answer
Options A and D are correct. Cognito User Pools can integrate with third-party IdPs. API Gateway can use Lambda authorizers to validate tokens.
Option B is wrong because IAM is for AWS users, not external IdPs directly. Option C is wrong because Secrets Manager is for secrets. Option E is wrong because STS is for temporary credentials, not authentication.
A company is using Amazon S3 to store sensitive documents. The security team requires that all access to the bucket be logged for audit purposes. Which feature should be enabled?
Server access logs record detailed information about requests.
Why this answer
S3 server access logging provides detailed records for requests made to an S3 bucket, including the requester, bucket name, request time, action, and response status. This feature logs all access at the object level, which directly meets the audit requirement for sensitive documents. It delivers log files to a target bucket in a standardized format, enabling security teams to analyze access patterns and detect unauthorized activity.
Exam trap
The trap here is that candidates often confuse AWS CloudTrail (Option D) with S3 server access logging, assuming CloudTrail's data events provide the same granularity, but CloudTrail is designed for API call auditing and may miss certain access patterns (e.g., anonymous requests or cross-account access) unless explicitly configured, whereas S3 server access logging captures all requests by default.
How to eliminate wrong answers
Option B is wrong because Amazon CloudWatch Logs is a service for monitoring, storing, and accessing log files from AWS resources like EC2 or Lambda, but it does not natively capture S3 access logs without additional configuration (e.g., using S3 event notifications to push logs to CloudWatch). Option C is wrong because S3 Inventory provides a list of objects and their metadata (e.g., size, encryption status) for compliance and lifecycle management, but it does not log access requests or actions performed on the bucket. Option D is wrong because AWS CloudTrail records management events (e.g., bucket creation, policy changes) and data events (e.g., GetObject, PutObject) for S3, but it is not the primary feature for detailed, request-level logging; S3 server access logging is the dedicated feature for granular access logs, while CloudTrail is often used for governance and compliance at a higher level.
Match each DynamoDB concept to its description.
Drag a concept onto its matching description — or click a concept then click the description.
Primary key for hashing
Range key for ordering
Alternate access pattern
Same partition key, different sort
In-memory cache for DynamoDB
Why these pairings
DynamoDB is a major topic in the exam.
A developer is configuring an S3 bucket to host a static website. The bucket must be accessible to anyone on the internet, but only for reading objects. Which THREE steps are necessary? (Choose THREE.)
Required for website access.
Why this answer
Option C is correct because enabling static website hosting on the S3 bucket is a prerequisite for serving content as a website. Without this setting, the bucket cannot serve HTTP requests for web pages, even if objects are publicly readable. This configuration provides an endpoint URL and allows index and error document routing.
Exam trap
The trap here is that candidates often assume setting a bucket ACL to public-read (Option A) is sufficient, but they forget that S3 Block Public Access settings must be disabled first, and ACLs are deprecated in favor of bucket policies for this use case.
A developer needs to securely distribute temporary AWS credentials to authenticated mobile users. Which two components are commonly involved?
Correct for the stated requirement.
Why this answer
Amazon Cognito identity pools allow you to exchange identity tokens (from a user pool or external IdP) for temporary AWS credentials via the AWS Security Token Service (STS). These credentials are scoped to an IAM role with fine-grained permissions, enabling secure, least-privilege access to AWS resources from mobile apps without embedding long-term keys.
Exam trap
The trap here is that candidates confuse Cognito user pools (which handle authentication and issue JWTs) with identity pools (which provide temporary AWS credentials), or mistakenly think root keys or open bucket policies are acceptable for mobile distribution.
A Lambda function needs to read from a DynamoDB table and send messages to an SQS queue. The function's IAM role should follow the principle of least privilege. Which policy statement should be attached to the role?
Grants only GetItem on the specific table and SendMessage on the specific queue.
Why this answer
Option B is correct because it grants only the specific DynamoDB read action (GetItem) needed to read from the table and the specific SQS write action (SendMessage) needed to send messages to the queue, scoped to the exact resource ARNs. This adheres to the principle of least privilege by not allowing any unnecessary operations or resources.
Exam trap
The trap here is that candidates often choose a wildcard resource or overly broad actions (like dynamodb:* or sqs:*) because they think it's simpler, failing to recognize that the principle of least privilege requires scoping both actions and resources to the minimum necessary.
How to eliminate wrong answers
Option A is wrong because it grants all DynamoDB actions (dynamodb:*) on the table, which includes write, delete, and administrative operations far beyond the required read-only access. Option C is wrong because it uses a wildcard resource (*) for both DynamoDB and SQS, which would allow access to any table or queue in the account, violating least privilege. Option D is wrong because it includes dynamodb:PutItem (a write action) that is not needed, and also uses a wildcard resource (*) instead of restricting to the specific table ARN.
A developer needs to grant an IAM user read-only access to an S3 bucket named 'my-bucket'. Which IAM policy statement should be attached?
This grants read-only access.
Why this answer
Option B is correct because it grants read-only access by allowing the `s3:GetObject` action (to read objects) and the `s3:ListBucket` action (to list objects in the bucket). The resources are correctly specified: `arn:aws:s3:::my-bucket` for the bucket-level `ListBucket` action and `arn:aws:s3:::my-bucket/*` for the object-level `GetObject` action. This combination provides the minimal permissions needed for read-only access without allowing write or delete operations.
Exam trap
The trap here is that candidates often forget to include both the bucket ARN and the object ARN, or they mistakenly use a single ARN like `arn:aws:s3:::my-bucket/*` for both actions, which would fail for `s3:ListBucket` because it requires the bucket-level ARN.
How to eliminate wrong answers
Option A is wrong because it allows all S3 actions (`s3:*`) on the bucket, which grants full administrative access, not read-only. Option C is wrong because it uses a `Deny` effect on `s3:GetObject`, which explicitly blocks read access, the opposite of what is needed. Option D is wrong because it allows `s3:PutObject` and `s3:DeleteObject`, which are write and delete operations, not read-only.
An application receives webhooks from a partner. The developer must verify that each request was signed by the partner and not modified in transit. What should the application validate?
Correct for the stated requirement.
Why this answer
Option C is correct because webhook verification relies on validating a cryptographic signature (HMAC or digital signature) computed over the request payload using a pre-shared secret or public key. This ensures the payload was signed by the partner and has not been tampered with during transit, as any modification would invalidate the signature. The application must recompute the HMAC or verify the digital signature using the partner's public key and compare it to the signature provided in the request header.
Exam trap
The trap here is that candidates confuse request metadata (like source port or request ID) with cryptographic verification mechanisms, assuming any unique identifier can prove authenticity, when only HMAC or digital signatures provide integrity and sender verification.
How to eliminate wrong answers
Option A is wrong because the source port number is a transient network-layer attribute that can be spoofed or changed by NAT/firewalls, and it provides no cryptographic proof of authenticity or integrity. Option B is wrong because a CloudWatch log stream name is an AWS-specific logging resource identifier unrelated to request signing or payload integrity verification. Option D is wrong because an API Gateway request ID is a unique identifier for debugging and tracing, not a cryptographic mechanism to verify the sender's identity or detect payload tampering.
The condition aws:SecureTransport with value 'false' matches requests that are not using HTTPS. Adding a Deny effect with this condition enforces HTTPS.
Why this answer
Option A is correct because the `aws:SecureTransport` condition key evaluates to `false` when the request is not sent over HTTPS (TLS). By using a Deny effect with this condition set to `false`, the policy blocks any HTTP requests to the S3 bucket, ensuring all traffic uses encrypted connections. This is a standard approach for enforcing TLS on S3 buckets, including those used for static website hosting.
Exam trap
The trap here is that candidates often confuse `aws:SecureTransport` with `aws:SourceVpc` or `aws:Referer`, or mistakenly think setting the condition to `true` in a Deny statement will block non-HTTPS traffic, when in fact it would block HTTPS traffic instead.
How to eliminate wrong answers
Option B is wrong because setting `aws:SecureTransport` to `true` would allow only HTTPS requests, but the question requires denying non-HTTPS requests; a Deny policy with `true` would block HTTPS traffic, which is the opposite of the desired outcome. Option C is wrong because `aws:SourceVpc` is used to restrict requests to those originating from a specific VPC, not to enforce HTTPS; setting it to `true` is invalid as this condition key expects a VPC ID, not a boolean. Option D is wrong because `aws:Referer` is used to restrict requests based on the HTTP Referer header (e.g., to prevent hotlinking), not to enforce HTTPS; the value `https` is a protocol scheme, not a valid referer pattern, and this condition does not check transport security.
A developer attached the above IAM policy to an IAM user. The user is trying to get an object from the bucket 'example-bucket' from an on-premises machine with public IP 203.0.113.5. What will happen?
The condition requires the source IP to match 10.0.0.1/32.
Why this answer
Option C is correct because the policy allows s3:GetObject only from IP 10.0.0.1/32. Since the request comes from 203.0.113.5, the condition fails, and access is denied. Option A is wrong because the condition is not ignored.
Option B is wrong because the condition explicitly restricts to a specific IP. Option D is wrong because the condition restricts to a specific IP, not a VPN.
A developer needs to call AWS APIs from application code running on EC2. Which credential source should the AWS SDK use by default?
Correct for the stated requirement.
Why this answer
Option D is correct because the AWS SDK on EC2 automatically retrieves temporary credentials from the instance metadata service (IMDS) at http://169.254.169.254/latest/meta-data/iam/security-credentials/. These credentials are provided by the IAM role attached to the EC2 instance (the instance profile role) and are rotated automatically, eliminating the need to store long-term credentials on the instance.
Exam trap
The trap here is that candidates may think manually embedding credentials (via a file or environment variable) is acceptable, but the AWS SDK on EC2 is designed to use the instance profile role by default, and any static credential source is both insecure and not the default behavior.
How to eliminate wrong answers
Option A is wrong because committing static credentials to Git is a severe security risk and violates AWS best practices; the SDK does not default to Git-stored credentials. Option B is wrong because copying a credentials file into the AMI embeds long-term credentials in the image, which can be exposed if the AMI is shared or reused, and the SDK does not default to an AMI-embedded file. Option C is wrong because root account access keys are highly privileged, static, and should never be used in application code; the SDK does not default to root keys.
A company uses AWS KMS to encrypt data at rest in S3. The security team wants to audit all use of the KMS key, including decryption operations. What should the developer enable?
CloudTrail data events capture KMS Decrypt and other operations on the key, providing full auditability.
Why this answer
AWS CloudTrail logs all KMS API calls, including Decrypt, Encrypt, and GenerateDataKey. This provides the audit trail required. Option A is wrong because S3 server access logs do not include KMS operation details.
Option C is wrong because CloudWatch Logs is for log storage, not for capturing API calls. Option D is wrong because AWS Config records resource configuration changes, not API calls.
A developer is deploying an application on Amazon ECS with Fargate. The application needs to access an S3 bucket that contains sensitive data. The developer wants to avoid storing AWS credentials in the container image. What is the MOST secure way to grant the application access to the S3 bucket?
Task roles provide credentials automatically via ECS.
Why this answer
Option D is correct because an IAM task role for ECS tasks allows the container to assume the role without storing credentials. Option A is wrong because environment variables are not secure. Option B is wrong because mounting credentials in a volume is insecure.
Option C is wrong because IAM roles for EC2 are for EC2 instances, not Fargate tasks.
A developer is building a mobile application that uses Amazon Cognito User Pools for authentication. The app needs to access a REST API hosted on AWS. The developer wants to use Cognito to authorize API requests. The API Gateway is configured with a Cognito User Pool authorizer. However, when testing, the API returns a 401 Unauthorized error even though the user is authenticated. The developer verified that the user exists in the user pool and the ID token is valid. What is the MOST likely cause and solution?
API Gateway expects the token in the Authorization header by default.
Why this answer
Option A is correct because the API Gateway authorizer expects an Authorization header with the token, and if the token is missing or in the wrong header, it returns 401. Option B is wrong because the method request header is not needed. Option C is wrong because the token should be the ID token, not access token.
Option D is wrong because the Authorizer is already configured.
A developer needs to grant an IAM user in Account A access to an S3 bucket in Account B. What is the correct combination of policies?
Both policies are required for cross-account access.
Why this answer
Option B is correct because cross-account S3 access requires two policies: an IAM policy in the source account (Account A) granting the user permission to perform S3 actions on the bucket, and a bucket policy in the target account (Account B) that explicitly allows the IAM user's ARN. The bucket policy acts as a resource-based policy that delegates access to the external principal, while the IAM policy authorizes the user to make the request. Without both, the request will be denied by either the source account's implicit deny or the target account's default deny.
Exam trap
The trap here is that candidates often think a bucket policy alone is sufficient for cross-account access (Option A), forgetting that the IAM user's own account must also explicitly authorize the action through an IAM policy.
How to eliminate wrong answers
Option A is wrong because an S3 bucket policy alone in Account B that allows the IAM user's ARN is insufficient — the IAM user in Account A still needs an IAM policy that explicitly grants permission to perform the S3 action, otherwise the request is denied by the source account's implicit deny. Option C is wrong because bucket ACLs do not support granting access to IAM users from another AWS account; ACLs only support AWS accounts or predefined groups, not individual IAM user ARNs. Option D is wrong because while creating an IAM role in Account B and allowing the user to assume it is a valid cross-account access pattern, the question specifically asks for granting access to an IAM user directly, not via role assumption; additionally, the bucket policy would need to allow the role's ARN, not the user's ARN, making this a different mechanism than what the question describes.
A company uses a customer managed AWS KMS key to encrypt sensitive data stored in DynamoDB. A Lambda function reads from the DynamoDB table and needs to decrypt the data. The Lambda function's execution role has an IAM policy that allows kms:Decrypt on the key. However, access is denied. What must the developer add to the KMS key policy to resolve the issue?
Correct. The key policy must explicitly allow the IAM role to perform kms:Decrypt.
Why this answer
The correct answer is A because KMS key policies are resource-based policies that control access to the key itself. Even if the Lambda execution role has an IAM policy granting kms:Decrypt, the KMS key policy must explicitly allow the role (or the user/account) to perform that action. Without this statement in the key policy, the IAM permission is ineffective, resulting in an access denied error.
Exam trap
The trap here is that candidates often assume IAM permissions alone are sufficient for KMS operations, forgetting that KMS key policies act as an additional layer of access control that must explicitly allow the principal.
How to eliminate wrong answers
Option B is wrong because Lambda functions do not have resource-based policies that can grant KMS permissions; KMS actions must be authorized via the key policy or IAM, not a Lambda resource policy. Option C is wrong because granting kms:Decrypt to the Lambda service principal would allow any Lambda function in the account to decrypt using the key, which is overly permissive and not the correct way to grant access to a specific function. Option D is wrong because granting kms:Decrypt to the account root user with a condition for the Lambda function is unnecessarily complex and not a standard pattern; the root user already has full control over the key, and conditions cannot directly reference a Lambda function's identity in a reliable way.
A company uses an AWS Lambda function to process files uploaded to an S3 bucket. The Lambda function needs to read the files and write results to a DynamoDB table. The Lambda function is configured with an IAM role that has policies allowing s3:GetObject on the bucket and dynamodb:PutItem on the table. Despite correct permissions, the function fails with an AccessDenied error when trying to put items. What is the most likely cause?
Resource-based policies can override IAM permissions.
Why this answer
The correct answer is B because DynamoDB tables can have resource-based policies that explicitly deny access even if the IAM role has the necessary permissions. Since explicit denies in resource-based policies override any allow in identity-based policies, the Lambda function's IAM role with dynamodb:PutItem permission is still blocked, causing the AccessDenied error.
Exam trap
The trap here is that candidates often assume IAM role permissions alone guarantee access, forgetting that resource-based policies on DynamoDB tables can explicitly deny access, which overrides any allow in identity-based policies.
How to eliminate wrong answers
Option A is wrong because a Lambda function in a VPC without a VPC endpoint for DynamoDB would cause a network timeout or connectivity error, not an AccessDenied error, as DynamoDB calls go over HTTPS and the error would be a timeout or connection failure, not an IAM permission denial. Option C is wrong because S3 and DynamoDB are both global services; cross-region access is fully supported and does not cause AccessDenied errors—the error would be a different type like a timeout or throttling if there were latency issues. Option D is wrong because while KMS permissions are needed for encrypted tables, the error message would be a KMS AccessDenied or a 400 error, not a generic AccessDenied on PutItem, and the question states the function fails specifically when trying to put items, not during encryption/decryption.
A developer is using AWS Lambda and needs to ensure that the function can access an RDS database securely. Which THREE steps should be taken?
Enables private access to RDS.
Why this answer
Option A, C, and E are correct. Option A: Lambda should be in a VPC to access RDS privately. Option C: Database credentials should be stored in Secrets Manager.
Option E: Security group should allow ingress from Lambda. Option B is wrong because Lambda does not use IAM roles for database authentication (it uses traditional credentials). Option D is wrong because Lambda cannot use client certificates for RDS.
The authorizer's context output is automatically passed to the backend as a JSON object.
Why this answer
The Lambda authorizer returns an IAM policy and a context map. The context map is included in the integration request and passed to the backend. Option A is wrong because the principal ID is a single field, not a full context.
Option C is wrong because the authorization token is the input, not the output. Option D is wrong because resource paths are not used to pass context.
A developer needs to grant a user in another AWS account (Account B) read-only access to objects in an Amazon S3 bucket owned by Account A. The developer has already added a bucket policy that grants s3:GetObject access to the IAM user in Account B. However, the user in Account B still gets Access Denied when trying to read objects. What additional configuration is required?
Cross-account access requires both a bucket policy that grants the user permissions and an IAM policy in the user's account that allows the action. The IAM policy is necessary because the default is to deny all actions.
Why this answer
The bucket policy in Account A grants s3:GetObject access to the IAM user in Account B, but this alone is insufficient. For cross-account access, the IAM user in Account B must also have an IAM policy attached that explicitly allows s3:GetObject on the bucket ARN. Without this, the user’s own account denies the request before it reaches Account A’s bucket policy, resulting in Access Denied.
Exam trap
The trap here is that candidates assume a bucket policy alone is sufficient for cross-account access, overlooking the requirement for an explicit IAM policy in the requesting account to allow the action.
How to eliminate wrong answers
Option B is wrong because making the bucket public by unchecking 'Block all public access' would grant anonymous access to everyone, which violates the principle of least privilege and is not required for a specific cross-account user. Option C is wrong because while creating an IAM role in Account A and having the user in Account B assume it is a valid alternative approach, it is not the additional configuration required here—the developer has already chosen a bucket policy approach, and the missing piece is the IAM policy in Account B. Option D is wrong because the S3 console and AWS CLI both enforce the same IAM permissions; the issue is a lack of permissions, not the tool used.
A company is using AWS CodeBuild to build a Docker image and push it to Amazon ECR. Which permissions are required for the CodeBuild service role? (Choose THREE.)
Needed to upload the Docker image.
Why this answer
Option A is correct because `ecr:PutImage` is the permission required to push a Docker image to an Amazon ECR repository. When CodeBuild completes a build and runs `docker push`, it calls the ECR API `PutImage` to upload the image manifest. Without this permission, the push operation will fail with an access denied error.
Exam trap
The trap here is that candidates may confuse `ecr:PutImage` with the non-existent `ecr:CreateImage` or mistakenly think `ecr:BatchGetImage` is needed for pushing, when in fact it is only used for pulling images.
A developer stores database credentials for an application running on Amazon EC2. The security team requires that the credentials be automatically rotated every 30 days to reduce the risk of compromise. Which AWS service should the developer use to store and automatically rotate the credentials?
Secrets Manager offers automatic rotation of secrets with built-in integration for RDS and other services. It can be configured to rotate every 30 days easily.
Why this answer
AWS Secrets Manager is the correct choice because it is specifically designed to securely store database credentials and other secrets, and it provides built-in, configurable automatic rotation (e.g., every 30 days) using AWS Lambda. This meets the security team's requirement without custom scripting or infrastructure management.
Exam trap
The trap here is that candidates often confuse AWS Systems Manager Parameter Store (which can store secrets but lacks native automatic rotation) with AWS Secrets Manager, leading them to choose Parameter Store for its lower cost or familiarity, despite the explicit rotation requirement.
How to eliminate wrong answers
Option A is wrong because AWS Systems Manager Parameter Store can store credentials but does not natively support automatic rotation; rotation would require custom automation with Lambda or other services, making it less suitable for this requirement. Option C is wrong because AWS Key Management Service (KMS) is a key management service for encryption keys, not for storing or rotating database credentials; it can encrypt secrets but does not manage rotation of the credentials themselves. Option D is wrong because IAM Roles for EC2 provide temporary credentials for AWS API access, not for storing or rotating database credentials; they cannot be used to store or rotate application-level database passwords.
Which TWO are best practices for securing an AWS account? (Choose 2)
MFA adds an extra layer of security.
Why this answer
Options A and B are best practices: using IAM roles and enabling MFA. Option C is not a best practice (root user should not be used for daily tasks). Option D is not a best practice (password policies should enforce complexity).
Option E is not a best practice (CloudTrail should be enabled).
A developer is troubleshooting an application that uses an IAM role to access DynamoDB. The application is running on an EC2 instance and intermittently fails with an AccessDenied error. The IAM role has the following policy attached. What is the MOST likely cause?
The condition restricts access to a specific IP range, which may not match the instance's IP.
Why this answer
Option D is correct because the IAM policy grants access to all tables ("*" in Resource) but only for specific actions. However, the condition "aws:SourceIp" might be too restrictive if the EC2 instance's IP changes (e.g., if it's behind a NAT gateway or uses an Elastic IP). Option A is wrong because the policy allows dynamodb:*.
Option B is wrong because there is no condition limiting to specific tables. Option C is wrong because the policy does not have a NotAction block.
A developer is building a serverless application using AWS Lambda. The Lambda function needs to write logs to CloudWatch Logs. What is the recommended way to grant the necessary permissions?
Lambda assumes this role to access AWS services.
Why this answer
Option B is correct because AWS Lambda uses an IAM execution role to obtain temporary credentials for accessing other AWS services. To allow a Lambda function to write logs to CloudWatch Logs, you must attach an IAM role with a policy that includes permissions for the `logs:CreateLogGroup`, `logs:CreateLogStream`, and `logs:PutLogEvents` actions. This is the standard and recommended security practice for granting permissions to Lambda functions.
Exam trap
The trap here is that candidates often confuse resource-based policies (which control who can invoke the function) with execution roles (which control what the function can do), leading them to incorrectly select option C.
How to eliminate wrong answers
Option A is wrong because AWS KMS is used for encryption key management, not for granting permissions; it does not provide IAM-level access control for writing logs. Option C is wrong because resource-based policies on a Lambda function control who can invoke the function, not what the function itself can do (like writing to CloudWatch Logs); permissions for the function's actions are defined in its execution role. Option D is wrong because storing AWS access keys in environment variables is a security anti-pattern; Lambda should never use long-term credentials, and instead relies on the IAM execution role to provide temporary, automatically rotated credentials.
An application running on an EC2 instance needs to access a DynamoDB table. The instance is in a private subnet without internet access. Which method should be used to grant the instance access to DynamoDB securely?
VPC endpoint enables private connectivity; IAM role provides temporary credentials.
Why this answer
Option D is correct because a VPC Gateway Endpoint for DynamoDB allows EC2 instances in a private subnet to access DynamoDB without traversing the internet or requiring a NAT gateway. By attaching an IAM role to the EC2 instance, the application can securely obtain temporary credentials via the instance metadata service, eliminating the need to store long-term credentials on the instance.
Exam trap
The trap here is that candidates often confuse security groups with network routing, assuming that allowing outbound traffic to DynamoDB's IP range is sufficient, but without a VPC endpoint or internet gateway, the traffic has no route to reach the DynamoDB service.
How to eliminate wrong answers
Option A is wrong because storing AWS credentials in a file on the instance is a security risk and violates the principle of least privilege; it also requires managing long-term keys, which can be rotated or compromised. Option B is wrong because security groups control network traffic at the instance level, but DynamoDB is a managed service outside the VPC; without a VPC endpoint or internet access, security group rules alone cannot route traffic to DynamoDB. Option C is wrong because a NAT gateway would provide internet access, but it introduces additional cost and complexity, and using IAM user credentials on the instance still requires managing long-term keys; the recommended approach is to use an IAM role with a VPC endpoint.
A developer is building a serverless application using API Gateway and Lambda. The developer needs to authenticate users with a JWT token. Which API Gateway feature should be used?
API Gateway JWT authorizer validates JWTs from a third-party issuer.
Why this answer
Option C is correct because API Gateway's JWT Authorizer is specifically designed to validate JSON Web Tokens (JWTs) directly, without invoking a Lambda function. It verifies the token's signature, expiry, and issuer against a specified issuer URL and audience, making it the most efficient and purpose-built choice for JWT authentication in API Gateway.
Exam trap
The trap here is that candidates often confuse the JWT Authorizer with a Lambda Authorizer, thinking they need custom code to validate a JWT, when in fact the JWT Authorizer handles standard JWT validation natively without a Lambda function.
How to eliminate wrong answers
Option A is wrong because a Lambda Authorizer (formerly Custom Authorizer) is used when you need custom validation logic beyond simple JWT verification, such as calling an external identity provider or performing complex claims mapping; it introduces unnecessary latency and cost for straightforward JWT validation. Option B is wrong because IAM Authorizer uses AWS Signature Version 4 (SigV4) for request signing and is intended for AWS service-to-service or IAM user authentication, not for validating externally-issued JWTs. Option D is wrong because Amazon Cognito User Pools is a full identity provider that issues JWTs, but it is not an API Gateway authorizer feature; you would still need to use a JWT Authorizer or Lambda Authorizer to validate those tokens in API Gateway.
A company requires that all API calls to create an Amazon S3 bucket must include a specific tag (e.g., 'CostCenter'). Which IAM policy condition key should a developer use to enforce this requirement?
This condition key checks tags that are included in the API request. You can require a specific tag key and value to be present on the CreateBucket request, ensuring that all buckets are tagged at creation.
Why this answer
Option A is correct because the `aws:RequestTag` condition key evaluates the tags that are included in the API request itself. When a developer attempts to create an S3 bucket, the IAM policy can use `aws:RequestTag` to require that a specific tag key (e.g., 'CostCenter') is present in the `CreateBucket` request. This ensures that the tag is applied at creation time, enforcing the company's tagging requirement.
Exam trap
The trap here is that candidates confuse `aws:RequestTag` (tags in the request) with `aws:ResourceTag` (tags on an existing resource), leading them to choose the wrong condition key for enforcing tagging at resource creation.
How to eliminate wrong answers
Option B is wrong because `aws:ResourceTag` evaluates the tags already attached to an existing resource, not the tags in the creation request, so it cannot enforce tagging at bucket creation. Option C is wrong because `s3:ExistingObjectTag` is used to conditionally allow actions based on tags on existing objects within a bucket, not on the bucket creation request itself. Option D is wrong because `aws:TagKeys` is used to restrict which tag keys can be used in a request, but it does not require that a specific tag key be present; it only controls the allowed set of keys.
A company is using AWS Key Management Service (KMS) to encrypt data in S3. The security team wants to ensure that only the company's AWS account can access the KMS key. What should be done?
Key policies control access to the key.
Why this answer
Option C is correct because modifying the key policy to deny access to external accounts ensures only the own account can use the key. Option A is wrong because IAM policies alone cannot prevent access if the key policy grants access to others. Option B is wrong because disabling the key prevents all use.
Option D is wrong because S3 bucket policies do not control KMS key access.
Correct for the stated requirement.
Why this answer
Option C is correct because an HTTP API Gateway with an external OIDC provider requires a JWT authorizer. The JWT authorizer validates the token's signature, issuer, and audience against the OIDC provider's configuration, ensuring only authenticated users gain access. This is the native AWS mechanism for integrating third-party OIDC identity providers like Auth0 or Okta.
Exam trap
The trap here is that candidates confuse the JWT authorizer with the Lambda authorizer, thinking a custom Lambda is always required for OIDC, but the JWT authorizer natively supports OIDC without custom code when the provider issues standard JWTs.
How to eliminate wrong answers
Option A is wrong because an IAM authorizer uses AWS Signature Version 4 for signing requests with IAM credentials, not OIDC tokens, and is designed for AWS-authenticated principals, not external identity providers. Option B is wrong because an API key authorizer only validates a static key passed in the header, which provides no authentication of the user's identity and cannot verify OIDC tokens. Option D is wrong because an S3 bucket policy controls access to S3 resources, not API Gateway endpoints, and has no mechanism to validate OIDC tokens.
A Lambda authorizer can validate custom tokens and return an IAM policy based on JWT claims, offering full control over authorization logic.
Why this answer
A Lambda authorizer (formerly known as a custom authorizer) is the correct choice because it allows the developer to validate a custom JWT and extract claims such as user roles directly within the Lambda function. This enables fine-grained authorization logic that can inspect the JWT payload, verify its signature using a custom or third-party key, and return an IAM policy based on the claims, which API Gateway then enforces for the incoming request.
Exam trap
The trap here is that candidates often confuse a Lambda authorizer with a Cognito user pools authorizer, assuming any JWT can be validated by Cognito, but Cognito only accepts tokens it issued, not custom JWTs from other providers.
How to eliminate wrong answers
Option B is wrong because an IAM authorizer uses AWS Signature Version 4 to sign requests with IAM credentials, not a custom JWT; it cannot inspect or validate JWT claims like user roles. Option C is wrong because Amazon Cognito user pools authorizer only works with JWTs issued by a Cognito user pool, not with a custom JWT from an external identity provider or self-issued token. Option D is wrong because an API Gateway resource policy controls access at the account or VPC level based on source IP, VPC endpoint, or AWS account, not on individual request-level JWT claims or user roles.
A developer needs to allow an IAM user to perform only specific actions on an S3 bucket. Which type of policy should be attached to the IAM user?
IAM policies are attached to users, groups, or roles to grant permissions.
Why this answer
An IAM policy (Option D) is the correct choice because it is an identity-based policy that can be directly attached to an IAM user, group, or role to grant or deny permissions for specific actions on AWS resources, including S3 buckets. This allows the developer to precisely control which S3 actions (e.g., s3:GetObject, s3:PutObject) the user can perform on a particular bucket, meeting the requirement of limiting the user to specific actions.
Exam trap
AWS often tests the distinction between identity-based policies (IAM policies) and resource-based policies (bucket policies), where candidates mistakenly choose a bucket policy thinking it can control user permissions directly, but bucket policies are tied to the resource, not the user identity.
How to eliminate wrong answers
Option A is wrong because a service control policy (SCP) is used in AWS Organizations to set permission boundaries for all accounts in an organization, not to grant permissions to individual IAM users. Option B is wrong because a bucket policy is a resource-based policy attached directly to an S3 bucket, not to an IAM user; while it can grant cross-account access, it does not control permissions for a specific IAM user within the same account. Option C is wrong because a trust policy is attached to an IAM role to define which principals (e.g., users, services) can assume that role, not to grant direct permissions for S3 actions to an IAM user.
A company wants to audit all API calls made in their AWS account for security analysis. Which TWO services should be used together to achieve this?
Records API calls for auditing.
Why this answer
AWS CloudTrail is the service that records all API calls made in an AWS account, capturing details like the identity of the caller, time of the call, source IP address, and request parameters. Amazon CloudWatch Logs can then be used to store, monitor, and alert on those CloudTrail logs for security analysis, enabling custom metrics and real-time anomaly detection. Together, they provide a complete audit trail and operational visibility for security auditing.
Exam trap
The trap here is that candidates often confuse AWS Config (which tracks resource configuration changes) with CloudTrail (which records API calls), leading them to select AWS Config instead of CloudTrail for auditing API activity.
A developer runs a CloudTrail lookup command and sees a CreateKey event. What does this event represent?
CreateKey is the API to create a CMK.
Why this answer
The `CreateKey` event in AWS CloudTrail indicates that a new KMS customer master key (CMK) was created. This is the only operation that generates a `CreateKey` event; key rotation, database encryption key creation, and service-linked key creation use different API calls (e.g., `RotateKey`, `CreateGrant`, or `CreateKey` with a different service principal).
Exam trap
The trap here is that candidates assume `CreateKey` only applies to CMKs, but AWS services also use this API for service-linked keys; however, the exam expects you to recognize that the event name is generic and the context (e.g., `userIdentity` or `requestParameters`) determines the key type.
How to eliminate wrong answers
Option A is wrong because key rotation is performed via the `RotateKey` API or automatic rotation settings, not `CreateKey`. Option B is wrong because database encryption keys are typically managed by the database service (e.g., RDS, DynamoDB) using KMS grants or direct CMK usage, not a standalone `CreateKey` event. Option D is wrong because service-linked keys are created by AWS services on your behalf using a different API call (e.g., `CreateKey` with a service principal), but the event name is still `CreateKey`; however, the question's context implies a standard CMK creation, and service-linked keys are a specific subset that would be logged with a different `requestParameters` (e.g., `KeyUsage` and `Origin`).
A developer needs to allow an EC2 instance to access an S3 bucket without storing credentials on the instance. Which approach is the most secure?
Best practice for EC2.
Why this answer
An IAM role attached to the EC2 instance provides temporary credentials via instance metadata, avoiding hardcoded keys.
A company needs to store application secrets such as database passwords and API keys. The secrets must be automatically rotated every 30 days. Which THREE AWS services or features can be used together to meet this requirement? (Choose THREE.)
Secrets Manager uses Lambda to rotate secrets.
Why this answer
AWS Lambda is correct because it can be used as a custom rotation function for AWS Secrets Manager. Secrets Manager natively supports automatic rotation using a Lambda function that updates the secret value in both the service and the database or third-party service. This allows the company to meet the 30-day rotation requirement by scheduling the Lambda function via a CloudWatch Events rule or Secrets Manager's built-in rotation schedule.
Exam trap
The trap here is that candidates often confuse AWS Systems Manager Parameter Store with Secrets Manager, but Parameter Store lacks native automatic rotation, making it unsuitable for this requirement without additional custom infrastructure.
A developer needs to securely pass a secret API key to an AWS Lambda function. What is the MOST secure and recommended approach?
Secrets Manager encrypts secrets and integrates with Lambda.
Why this answer
Option B is correct because AWS Secrets Manager stores secrets securely and Lambda can retrieve them at runtime. Option A is wrong because environment variables are visible in the console. Option C is wrong because storing in DynamoDB is less secure and requires additional permissions.
Option D is wrong because hardcoding in code is insecure.
A company uses AWS Organizations with multiple accounts. The security team wants to enforce that all S3 buckets across all accounts have server-side encryption enabled. They have created an SCP that denies the s3:PutBucketAcl action unless the request includes the x-amz-server-side-encryption header. However, some application teams report that they cannot create buckets even when they include the required header. What is the MOST likely cause of this issue?
The SCP should deny s3:CreateBucket unless encryption header is present.
Why this answer
Option A is correct because the SCP denies s3:PutBucketAcl, not s3:CreateBucket. The SCP should deny s3:CreateBucket unless the encryption header is present. Option B is wrong because SCPs do not evaluate resource-based policies.
Option C is wrong because SCPs apply to all principals in the account. Option D is wrong because the issue is with the SCP action, not the header condition.
A developer needs to allow an EC2 instance to access a DynamoDB table. Which IAM entity should be attached to the EC2 instance?
Roles provide temporary credentials to the instance.
Why this answer
An IAM role is the correct entity to attach to an EC2 instance because it provides temporary security credentials via the AWS Security Token Service (STS) that the instance can assume. This allows the EC2 instance to securely access the DynamoDB table without embedding long-term access keys in the instance. The role is attached to the instance profile, which the EC2 instance metadata service (IMDS) uses to retrieve credentials automatically.
Exam trap
The trap here is that candidates often confuse IAM roles with IAM users, thinking a user can be attached to an EC2 instance, but AWS does not allow attaching a user to a resource—only roles can be assumed by AWS services like EC2.
How to eliminate wrong answers
Option A is wrong because an IAM group is a collection of IAM users and cannot be directly attached to an EC2 instance; groups are used to manage permissions for users, not for AWS resources. Option C is wrong because an IAM user has long-term credentials (access key ID and secret access key) that would need to be stored on the EC2 instance, which is a security risk and not a best practice for granting permissions to an AWS service. Option D is wrong because a resource-based policy on the DynamoDB table can grant access to principals (like IAM roles or users) but cannot be attached to an EC2 instance; the EC2 instance itself must have an identity (role) to authenticate against the policy.
A company has a requirement that all API calls to AWS must be logged and monitored for suspicious activity. They want to receive alerts when root account activity is detected. Which AWS service and configuration should they use?
Correct combination for alerting.
Why this answer
Option B is correct because AWS CloudTrail captures all API calls, including those made by the root account. By creating a CloudWatch Events (now Amazon EventBridge) rule that matches the `userIdentity.type` field set to `Root` and the `eventSource` set to `signin.amazonaws.com`, you can trigger a Lambda function to send alerts or perform remediation. This provides real-time monitoring and notification for suspicious root account activity.
Exam trap
The trap here is confusing CloudTrail's logging capability with direct notification configuration—candidates often think SNS can be attached directly to CloudTrail, but CloudTrail requires an intermediary like CloudWatch Events to filter and route events to SNS or Lambda.
How to eliminate wrong answers
Option A is wrong because while CloudTrail logs root account events, SNS notifications cannot be directly configured on CloudTrail; you need a CloudWatch Events rule to filter and route the events to an SNS topic. Option C is wrong because VPC Flow Logs capture network traffic metadata (IP addresses, ports, protocols) at layer 3/4, not API call details; they cannot log or monitor AWS API calls. Option D is wrong because AWS Config rules evaluate resource configuration compliance (e.g., whether an S3 bucket is public), not user activity or API call patterns; they cannot detect root account usage.
A company wants to encrypt data at rest in an S3 bucket. Which AWS service can provide encryption keys that are managed by AWS and rotated automatically?
AWS manages and rotates keys.
Why this answer
SSE-S3 uses encryption keys that are managed entirely by AWS and are rotated automatically on a regular basis. This option meets the requirement for AWS-managed keys with automatic rotation without any additional configuration or cost.
Exam trap
The trap here is that candidates often confuse SSE-KMS with AWS-managed keys, but SSE-KMS uses customer-managed keys by default, and automatic rotation is only available for AWS-managed keys in KMS (which are not the default for SSE-KMS).
How to eliminate wrong answers
Option A is wrong because SSE-KMS uses AWS KMS keys, which are managed by the customer (customer-managed keys) by default and require manual rotation or configuration for automatic rotation, and incur additional costs. Option C is wrong because SSE-C requires the customer to provide and manage their own encryption keys, and AWS does not rotate them. Option D is wrong because client-side encryption is performed by the client application before data is sent to S3, and the keys are managed by the client, not by AWS.
A company is using AWS CodeCommit and wants to ensure that all commits are signed with GPG keys. Which approach should be used to enforce this?
IAM policies can enforce signed commits using conditions.
Why this answer
Option C is correct because AWS CodeCommit does not natively support a 'require signed commits' toggle in the repository settings. Instead, you must use an IAM policy with a condition key like `codecommit:referencedRefName` and a custom condition (e.g., using the `git` protocol's signed commit metadata) to deny `codecommit:GitPush` actions when the commit is not signed. This is the only way to enforce GPG signing at the AWS service level.
Exam trap
The trap here is that candidates assume CodeCommit has a simple 'require signed commits' toggle like other Git platforms, but AWS requires a custom IAM policy because CodeCommit lacks native server-side GPG verification.
How to eliminate wrong answers
Option A is wrong because AWS Organizations SCPs cannot inspect the content of individual Git commits or enforce signing; they operate at the account or organizational level and cannot evaluate commit-level metadata. Option B is wrong because CodeCommit does not have a built-in 'Require signed commits' setting in its repository configuration; this feature exists in other Git hosting services like GitHub or GitLab but not in CodeCommit. Option D is wrong because CodeCommit does not support pre-commit hooks; hooks are a client-side Git feature and cannot be enforced server-side via AWS Lambda.
A company has an IAM policy that allows access to an S3 bucket only if the request comes from a specific VPC endpoint. The developer notices that requests from an EC2 instance in that VPC are being denied. What is the most likely cause?
VPC endpoint policies can restrict what actions are allowed through the endpoint. If the policy denies 's3:GetObject' for the role or user, access will be denied even if IAM and bucket policies allow it.
Why this answer
The correct answer is A because the VPC endpoint policy is an additional layer of access control that can explicitly deny actions even if the bucket policy allows them. If the endpoint policy does not grant the required S3 action (e.g., s3:GetObject) for the IAM principal (the EC2 instance's role), requests will be denied regardless of the bucket policy. This is a common misconfiguration where developers focus only on the bucket policy and overlook the endpoint policy.
Exam trap
The trap here is that candidates assume the bucket policy is the only control point and overlook the VPC endpoint policy, which acts as a separate authorization layer that can silently deny requests even when the bucket policy appears correct.
How to eliminate wrong answers
Option B is wrong because the bucket policy condition checking aws:SourceVpce is necessary to restrict access to the VPC endpoint, but the question states the policy already allows access only from a specific VPC endpoint; the issue is that requests are denied, so the condition is likely present but the endpoint policy is blocking. Option C is wrong because the route table does not need a route to the S3 endpoint; VPC endpoints use prefix lists and route tables direct traffic to the endpoint via a gateway or interface endpoint, but missing routes would cause a timeout or connection failure, not an IAM denial. Option D is wrong because security groups do not apply to VPC endpoint traffic; S3 uses a gateway endpoint which is not associated with security groups, and outbound HTTPS traffic from the EC2 instance is allowed by default in the VPC.
A developer attaches this IAM policy. What happens when the developer attempts to launch a t2.micro instance?
Deny condition does not match t2.micro.
Why this answer
The Deny applies to instances that are NOT t2.micro. Since the condition uses StringNotEquals, the Deny does not apply to t2.micro. So the Allow takes effect.
A company has an Amazon S3 bucket (Bucket-A) in Account A that contains sensitive data. A developer in Account B needs read-only access to objects in Bucket-A. The developer in Account A added a bucket policy granting s3:GetObject to the IAM user in Account B. However, the IAM user in Account B still receives Access Denied errors. What additional step is required?
The user must have explicit permission from their own account to perform the action, in addition to the bucket policy.
Why this answer
The bucket policy in Account A grants access to the IAM user in Account B, but the user's identity in Account B must also have an explicit IAM policy that allows the s3:GetObject action. Without this, the user in Account B lacks the necessary permissions to access the bucket, even though the bucket policy permits it. This is because cross-account access requires both a resource-based policy (bucket policy) in the source account and an identity-based policy (IAM policy) in the target account to authorize the request.
Exam trap
The trap here is that candidates often assume a bucket policy alone is sufficient for cross-account access, forgetting that the IAM user in the target account must also have an explicit allow policy for the action.
How to eliminate wrong answers
Option A is wrong because S3 bucket ACLs are legacy and do not support granting access to IAM users in another AWS account; they only grant access to AWS accounts or predefined groups, not specific IAM users. Option C is wrong because generating pre-signed URLs is a workaround for temporary access, not a required step to fix the existing bucket policy and IAM user configuration; it would bypass the need for proper IAM policies but is not the missing step for the described setup. Option D is wrong because adding an IP address condition is unrelated to the cross-account permission issue; it would restrict access based on network location but does not resolve the missing identity-based policy in Account B.
A company is using an S3 bucket to store sensitive documents. They need to ensure that all objects are encrypted at rest using server-side encryption with AWS KMS. The bucket policy must enforce encryption by denying uploads that do not specify the required encryption. Which bucket policy statement should be added?
Correctly denies if not using KMS.
Why this answer
Option A is correct because the bucket policy uses the `s3:x-amz-server-side-encryption` condition key with `StringNotEquals` to deny any upload where the header does not specify `aws:kms`. This ensures that only objects encrypted with AWS KMS (SSE-KMS) are allowed, enforcing server-side encryption at rest. The `Deny` effect combined with this condition blocks requests that either omit the encryption header or specify a different value like `AES256`.
Exam trap
The trap here is that candidates often confuse the condition key `s3:x-amz-server-side-encryption` with the KMS-specific key `s3:x-amz-server-side-encryption-aws:kms` (which does not exist), or they mistakenly use `Null` to check for the header's presence without validating its value, allowing SSE-S3 (AES256) uploads to bypass the policy.
How to eliminate wrong answers
Option B is wrong because `s3:x-amz-server-side-encryption-aws:kms` is not a valid condition key; the correct key is `s3:x-amz-server-side-encryption` and the value should be `aws:kms`, not a boolean. Option C is wrong because using `Null: 's3:x-amz-server-side-encryption': 'true'` only denies requests where the header is absent, but it does not enforce that the encryption type is `aws:kms`; a request with `AES256` would still be allowed. Option D is wrong because `StringNotEquals: 's3:x-amz-server-side-encryption': 'AES256'` denies requests that do not use AES256, which would incorrectly allow `aws:kms` but also block legitimate SSE-KMS uploads if the policy is meant to require KMS; it also fails to block requests with no encryption header.
A company requires that all data in an S3 bucket be encrypted at rest. The security team wants to enforce that only objects encrypted with AWS KMS are allowed. Which S3 bucket policy condition key should be used to deny PutObject requests if the object is not encrypted with KMS?
This condition key allows you to require a specific KMS key ID.
Why this answer
Option D is correct because the `s3:x-amz-server-side-encryption-aws-kms-key-id` condition key specifically checks for the AWS KMS key ID (or alias) used for server-side encryption with AWS KMS (SSE-KMS). By using this key in a bucket policy with a `Deny` effect, you can enforce that only objects encrypted with a specific KMS key are allowed, rejecting any `PutObject` request that does not include the required `x-amz-server-side-encryption-aws-kms-key-id` header.
Exam trap
The trap here is that candidates confuse the valid condition key `s3:x-amz-server-side-encryption-aws-kms-key-id` with similar-sounding but invalid keys like `s3:x-amz-server-side-encryption-kms-key-id` (missing 'aws') or `s3:x-amz-server-side-encryption-key-id` (which does not exist), leading them to choose an option that AWS S3 will not evaluate.
How to eliminate wrong answers
Option A is wrong because `s3:x-amz-server-side-encryption-key-id` is not a valid S3 condition key; AWS S3 does not recognize this key. Option B is wrong because `s3:x-amz-server-side-encryption` only checks whether server-side encryption is enabled (e.g., AES256 or aws:kms), but it cannot enforce a specific KMS key ID, so it would allow SSE-S3 or any KMS key. Option C is wrong because `s3:x-amz-server-side-encryption-kms-key-id` is not a valid condition key; the correct key name includes 'aws' as `s3:x-amz-server-side-encryption-aws-kms-key-id`.
A developer receives an AccessDenied error when trying to upload a file to an S3 bucket that has a bucket policy requiring encryption in transit. What is the most likely cause?
The policy requires encryption in transit, which is HTTPS.
Why this answer
The bucket policy likely denies requests that are not using HTTPS. Option A (no encryption) would be denied if the policy requires encryption in transit. Option B (wrong permissions) would give a different error.
Option C (no server-side encryption) is about at-rest encryption, not in transit. Option D (expired signature) would give a different error.
A developer is troubleshooting an AccessDenied error when a Lambda function tries to write to CloudWatch Logs. The function's IAM role includes the following policy. Which TWO missing permissions are causing the error? (Choose TWO.)
Required to create a log stream.
Why this answer
Option C is correct because a Lambda function must call logs:CreateLogStream before it can write log events to a specific log stream. Without this permission, the function cannot create a new log stream when one does not already exist, resulting in an AccessDenied error. Option E is correct because logs:PutLogEvents is the permission required to actually write log events to an existing log stream; without it, the function cannot send log data to CloudWatch Logs.
Exam trap
The trap here is that candidates often assume only PutLogEvents is needed for writing logs, forgetting that the Lambda runtime must also create the log stream if it does not already exist, making CreateLogStream a required permission.
A company has a multi-account AWS environment using AWS Organizations. The security team wants to enforce that all S3 buckets across all accounts are encrypted with AES-256 using SSE-S3. They also want to automatically remediate any bucket that is created without encryption. The team currently uses AWS CloudFormation StackSets to deploy resources. They need a solution that does not require manual intervention. Which approach should be taken?
Detects and remediates non-compliant buckets.
Why this answer
Option B is correct because AWS Config can continuously evaluate S3 buckets against a custom rule that checks for SSE-S3 encryption. When a non-compliant bucket is detected, AWS Systems Manager Automation can automatically remediate it by applying the required encryption, meeting the requirement for automatic remediation without manual intervention.
Exam trap
The trap here is that candidates may confuse preventive controls (SCPs) with detective and corrective controls (Config + Automation), failing to realize that SCPs alone cannot remediate already non-compliant resources or enforce encryption on buckets created without encryption settings.
How to eliminate wrong answers
Option A is wrong because an SCP that denies s3:PutBucketEncryption would prevent any encryption changes, but it does not enforce encryption on newly created buckets (which default to no encryption) and does not provide automatic remediation. Option C is wrong because deploying a CloudFormation template via StackSets only creates buckets with encryption at deployment time; it does not detect or remediate buckets created outside of CloudFormation, such as those created manually or by other services. Option D is wrong because S3 Block Public Access controls public access settings, not encryption; it does not address the requirement to enforce SSE-S3 encryption.
A developer is deploying an application on EC2 that must access an S3 bucket. The developer wants to avoid hard-coding credentials. What is the MOST secure way to grant access?
Instance profiles deliver temporary credentials securely; no hard-coded keys needed.
Why this answer
Creating an IAM role with an instance profile and assigning it to the EC2 instance is the most secure method. It provides temporary credentials automatically via the EC2 metadata service. Option A is wrong because storing keys in a config file is not secure.
Option B is wrong because S3 bucket policies are resource-based and should be used in combination with IAM roles, but the primary method is the instance profile. Option D is wrong because environment variables can be read by processes and are less secure than instance profiles.
A developer is building a serverless application using AWS Lambda and API Gateway. The Lambda function needs to access a DynamoDB table that stores sensitive customer data. The developer wants to follow the principle of least privilege. Which IAM role configuration should be used?
This follows the principle of least privilege by granting only necessary actions on the specific table.
Why this answer
Option D is correct because it adheres to the principle of least privilege by granting only the specific DynamoDB actions (e.g., GetItem, PutItem) required by the Lambda function, scoped to the exact table. The Lambda execution role is an IAM role that the Lambda service assumes, and attaching a custom policy with fine-grained permissions ensures minimal access. This approach avoids over-permissioning and follows AWS security best practices for serverless applications.
Exam trap
The trap here is that candidates confuse resource-based policies (used for granting invoke permissions to Lambda) with execution role policies (used for granting the Lambda function access to other AWS services), leading them to pick Option A, which does not control DynamoDB access.
How to eliminate wrong answers
Option A is wrong because resource-based policies on Lambda functions control which other AWS services or accounts can invoke the function, not the function's own access to downstream resources like DynamoDB; Lambda uses execution roles for outbound permissions. Option B is wrong because AmazonDynamoDBFullAccess is a managed policy that grants unrestricted access to all DynamoDB actions on all tables, violating the principle of least privilege. Option C is wrong because S3 bucket policies are used to control access to S3 resources, not DynamoDB tables; DynamoDB access is governed by IAM policies attached to the caller's role, not by S3 policies.
A developer needs to grant read-only access to objects in an S3 bucket (in Account A) to an IAM role in Account B. The bucket uses server-side encryption with AWS KMS (SSE-KMS) using a customer managed key (CMK) in Account A. Which of the following is REQUIRED for the cross-account access to succeed?
All three policies are required: the bucket policy for S3 access, the KMS key policy for decryption permissions, and the trust policy in Account B to allow the IAM user to assume the role.
Why this answer
Option A is correct because cross-account access to an S3 bucket with SSE-KMS using a customer managed key requires three distinct permissions: the S3 bucket policy must grant s3:GetObject to the IAM role in Account B, the KMS key policy must grant kms:Decrypt to that same role (since KMS key policies are resource-based and do not trust IAM policies from other accounts), and the IAM role in Account B must have a trust policy that allows the IAM user to assume it. Without the KMS key policy explicitly allowing the external role, the decryption step will fail, even if the S3 bucket policy permits the read operation.
Exam trap
The trap here is that candidates assume IAM policies in the target account are sufficient for KMS operations, forgetting that KMS key policies are resource-based and must explicitly grant cross-account access, unlike S3 bucket policies which can reference external principals directly.
How to eliminate wrong answers
Option B is wrong because it omits the required KMS key policy entry; KMS key policies are resource-based and do not automatically extend trust to IAM principals in another account, so the IAM role in Account B cannot use the CMK for decryption without an explicit grant in the key policy. Option C is wrong because it grants access to an IAM user rather than an IAM role, and cross-account access via S3 bucket policies must be granted to a principal in the other account (such as an IAM role), not directly to an IAM user; additionally, the IAM user's own policy is irrelevant because the bucket policy is the controlling resource-based policy for S3 access. Option D is wrong because the question explicitly states the bucket uses SSE-KMS, not SSE-C, so the scenario of providing an encryption key in the request does not apply.
Ready to test yourself?
Try a timed practice session using only Dva Security questions.