Security practice questions

The S3 bucket does not have versioning enabled.

Why wrong: Versioning is not required for read access.

The Lambda function's execution role does not have an explicit allow for s3:GetObject.

Why wrong: The question states the role includes an IAM policy that allows s3:GetObject, so this is not the issue.

The Lambda function is not in the same AWS region as the S3 bucket.

Why wrong: Cross-region access is allowed with appropriate permissions, so this is not the cause.

Deny effect with a Condition: StringEquals on s3:x-amz-server-side-encryption

Why wrong: The condition key s3:x-amz-server-side-encryption only checks whether encryption is requested (e.g., AES256 or aws:kms), but does not specify which KMS key. Using StringEquals with this key would deny requests that do not use the encryption header, but it would not enforce the use of a specific KMS key.

Allow effect with a Condition: StringEquals on kms:RequestTag/key-id

Why wrong: SCPs cannot use Allow effect to explicitly allow actions; they are used to deny. Also, kms:RequestTag/key-id is not a valid condition key for S3 PutObject. This approach is incorrect and insecure.

Deny effect with a Condition: IpAddress on aws:SourceIp

Why wrong: This condition restricts access based on IP address, not encryption. It does not enforce the use of a specific KMS key and is irrelevant to the requirement.

The bucket must be made public by unchecking 'Block all public access'

Why wrong: Making the bucket public would allow everyone access, which is too permissive and violates the principle of least privilege. The correct approach is to use a combination of bucket and IAM policies.

The developer must create a new IAM role in Account A and have the user in Account B assume that role

Why wrong: While using role assumption is another valid cross-account access method, the question states the developer already used a bucket policy. The issue is likely the missing IAM user policy in Account B.

The user in Account B must use the S3 console instead of the AWS CLI

Why wrong: The access denied error is a permissions issue, not a tool issue. The console and CLI both enforce IAM and bucket policies.

Enable CloudTrail data events for the S3 bucket containing the encrypted objects.

Why wrong: S3 data events log S3 object-level operations (e.g., GetObject, PutObject), not KMS API calls. The KMS operations are separate.

Create an additional CloudTrail trail that logs all management events for the KMS key.

Why wrong: Management events already include KMS management operations, but not data operations like Encrypt and Decrypt. A separate trail will still only log management events unless data events are configured.

Enable CloudTrail Insights events on the existing trail.

Why wrong: Insights events detect unusual API activity but do not change which events are logged. The base event logging must still include data events.

The identity pool is not configured to use the authenticated role.

Why wrong: If the identity pool were not configured, the app would likely fail to obtain any credentials entirely, but the question states the developer set up the identity pool with an authenticated role, so this is not the most likely cause.

The app is not passing the correct identity ID.

Why wrong: The identity ID is assigned by Cognito; the AWS SDK automatically handles this. Passing an incorrect ID would cause authentication failures, but the scenario describes users signed in and still unable to perform operations.

The DynamoDB table is encrypted with a different KMS key.

Why wrong: If encryption with a customer-managed KMS key is used, the role would also need kms:Decrypt permissions, but the most likely initial cause is the trust policy issue.

Add a statement granting kms:Decrypt to the Lambda function's resource-based policy.

Why wrong: Lambda functions do not have resource-based policies for KMS; the key policy is the resource policy.

Add a statement granting kms:Decrypt to the Lambda service principal.

Why wrong: The service principal is not the entity that accesses the key; the execution role does.

Add a statement granting kms:Decrypt to the account root user with a condition for the Lambda function.

Why wrong: While the root user can delegate access via IAM, a condition on the root is not a secure or direct way to grant the Lambda role.

Use AWS Systems Manager Parameter Store with a SecureString parameter using an AWS managed key

Why wrong: Parameter Store does not support automated rotation of secret values; you would have to implement manual rotation, which does not meet the automatic quarterly requirement.

Encrypt the environment variables using the Lambda service key

Why wrong: The Lambda service key is AWS-managed and cannot be used for customer-scheduled rotation. Also, environment variables are not ideal for frequent rotation.

Use AWS KMS to encrypt the environment variables and set a manual rotation policy

Why wrong: Manual rotation does not satisfy the requirement for automatic quarterly rotation.

Add an S3 bucket ACL granting the user in Account B Read access

Why wrong: ACLs are not needed and do not resolve the missing IAM permission in Account B.

Generate a pre-signed URL for each object and share it with the user

Why wrong: Pre-signed URLs provide temporary access but are not a permanent solution and require manual management.

Add a condition in the bucket policy to allow requests only from the user's IP address

Why wrong: This would restrict access further, not solve the missing IAM permission issue.

"Condition": {"StringNotEquals": {"s3:x-amz-server-side-encryption": "aws:kms"}}

Why wrong: This condition only checks that SSE-KMS is used, but does not enforce a specific key ID. Any KMS key would be accepted.

"Condition": {"Null": {"s3:x-amz-server-side-encryption-aws-kms-key-id": "true"}}

Why wrong: This condition denies requests if the key ID header is present, which is opposite of the requirement.

"Condition": {"ArnNotEquals": {"s3:x-amz-server-side-encryption-aws-kms-key-id": "arn:aws:kms:us-east-1:123456789012:key/abc123"}}

Why wrong: The condition key 's3:x-amz-server-side-encryption-aws-kms-key-id' does not support ArnNotEquals; it uses StringNotEquals. Also, the key ID in the condition should be the full ARN.

s3:x-amz-server-side-encryption-aws-kms-key-id equals the KMS key ARN

Why wrong: This condition enforces the use of a specific KMS key, but does not require the encryption header itself. It can be used together with the encryption condition for a stricter policy.

s3:x-amz-acl equals 'bucket-owner-full-control'

Why wrong: This condition is for access control lists, not encryption.

s3:signatureversion equals 'AWS4-HMAC-SHA256'

Why wrong: This condition checks the signature version, not encryption headers.

Create an S3 access point and grant the user access through it.

Why wrong: S3 access points are not required for this scenario. They provide a simplified way to manage access but would not resolve the missing IAM policy issue.

Change the bucket policy to grant access to the entire AWS account B instead of the specific user.

Why wrong: Granting access to the entire account could violate least privilege and still does not address the need for the user to have an IAM policy allowing the action.

Enable S3 object ownership and set the bucket ACL to grant read access to the user in Account B.

Why wrong: S3 ACLs are legacy and not recommended. They also require the object owner to grant access, and the bucket policy is already in place. The missing piece is the IAM policy in the user's account.

AWS Systems Manager Parameter Store (SecureString)

Why wrong: Parameter Store can store encrypted parameters but does not offer automatic rotation; rotation must be implemented manually.

AWS Key Management Service (KMS)

Why wrong: KMS manages encryption keys, not application secrets like passwords.

AWS Identity and Access Management (IAM) roles

Why wrong: IAM roles provide temporary credentials for EC2 to access AWS services, but they cannot be used to store or rotate database passwords.

Condition with aws:SourceArn

Why wrong: Incorrect. aws:SourceArn is used to restrict requests to a specific resource ARN, not for an external identifier.

Condition with aws:SourceAccount

Why wrong: Incorrect. aws:SourceAccount restricts based on the AWS account ID of the resource, but it does not provide a unique identifier per vendor request.

Principal element with the vendor's AWS account ID

Why wrong: Incorrect. Specifying the principal alone does not enforce a unique identifier. The vendor could misuse the policy from other roles in their account.

Create an IAM user with access keys and store the keys in AWS Secrets Manager. Have the application retrieve the keys at runtime.

Why wrong: This approach uses long-term IAM user credentials, which violates the requirement to not use IAM users and to have automatically rotated credentials. While Secrets Manager can rotate IAM user keys, it still involves IAM users.

Use an AWS Lambda function to generate a pre-signed URL that allows access to DynamoDB, and have the EC2 instance use that URL.

Why wrong: Pre-signed URLs are not applicable to DynamoDB. They are used for S3 operations. Even for S3, this approach would require the Lambda function to have credentials, and the EC2 instance would not have direct access to DynamoDB.

Generate a long-lived API token using AWS KMS and embed it in the application code.

Why wrong: Embedding credentials in code is a security risk and violates the requirement for automatically rotated credentials. KMS is for encryption, not for generating API tokens for IAM.

Enable automatic rotation and choose a rotation interval of 30 days. Secrets Manager will automatically rotate the secret using a built-in Lambda function.

Why wrong: Secrets Manager requires a Lambda function to perform rotation; there is no built-in function for all secret types. The developer must provide or configure a rotation function.

Use AWS Certificate Manager (ACM) to rotate the secret automatically every 30 days.

Why wrong: ACM is for SSL/TLS certificates, not for database credentials.

Store the secret in AWS Systems Manager Parameter Store and set a schedule to rotate it using a CloudWatch Events rule.

Why wrong: While Parameter Store can store secrets, it does not have built-in rotation capabilities like Secrets Manager. The question specifies using Secrets Manager.

The bucket policy in Account A grants s3:GetObject to the role, and the role in Account B has an IAM policy allowing s3:GetObject. No KMS permissions are needed because SSE-KMS uses AWS managed keys by default.

Why wrong: The question specifies a customer managed key, which requires explicit key policy grants. AWS managed keys cannot be used in cross-account scenarios.

The bucket policy in Account A grants s3:GetObject to the role, and the KMS key policy grants kms:Decrypt to the role. The role in Account B does not need additional IAM policies because the bucket and key policies provide sufficient permissions.

Why wrong: IAM roles require IAM policies to authorize actions, even if resource-based policies grant access. The role must have an IAM policy allowing s3:GetObject and kms:Decrypt.

Only the bucket policy in Account A needs to grant s3:GetObject to the role. KMS is not involved because the bucket is encrypted with SSE-KMS but the role can decrypt using the default KMS key.

Why wrong: SSE-KMS with a customer managed key requires explicit KMS permissions. The default key (AWS managed key) cannot be used for cross-account access.

A policy that grants secretsmanager:GetSecretValue for all secrets in the account

Why wrong: This violates least privilege by granting access to all secrets.

A policy that grants secretsmanager:GetSecretValue for the secret and includes a condition for aws:SourceIp

Why wrong: The source IP for a Lambda function in a VPC is a private IP, which is not effective for restricting access via condition keys.

A policy that grants secretsmanager:GetSecretValue for the secret and includes a condition for ec2:Vpc

Why wrong: The ec2:Vpc condition key is not defined for Secrets Manager; the correct condition key for VPC endpoints is aws:SourceVpce.

Store the secret in Secrets Manager, create an IAM user with a policy to read the secret, and embed the user's credentials in the application code

Why wrong: Incorrect. Embedding credentials in code is a security risk; they can be exposed. Also, IAM users have long-term credentials, which are less secure than using roles with temporary credentials.

Store the secret as an environment variable in the EC2 user data

Why wrong: Incorrect. User data is visible in the EC2 console and logs, and environment variables can be exposed through the operating system. This is not secure.

Store the secret in a configuration file on the instance and restrict file permissions

Why wrong: Incorrect. Storing secrets in files on disk, even with restrictive permissions, is less secure than using AWS Secrets Manager with IAM roles because it requires managing file distribution and rotation manually.

Server-side encryption with an AWS managed KMS key

Why wrong: AWS managed keys are managed by AWS, not by the company's security team.

Client-side encryption

Why wrong: Client-side encryption happens before data is sent to DynamoDB; the question specifies encryption at rest.

Static key encryption

Why wrong: DynamoDB does not support 'static key' encryption; it uses KMS for SSE.

Create a new CMK every year and update the S3 bucket policy to use the new key.

Why wrong: This approach is manual, error-prone, and requires updating all references to the key, leading to high operational overhead.

Use an AWS managed key (aws/s3) which automatically rotates annually.

Why wrong: AWS managed keys rotate annually, but they are not customer managed keys and do not allow customization of key policies or auditing as required by the company.

Use SSE-S3 encryption with automatically rotated keys instead of KMS.

Why wrong: SSE-S3 provides server-side encryption with Amazon-managed keys that are rotated, but it does not allow the use of customer-managed keys or compliance tracking requirements.