AWS DVA-C02: Security Practice Questions

Least-privilege means granting only the specific actions needed on the specific resources. dynamodb:PutItem on the exact table ARN grants only the write permission needed for DynamoDB. sns:Publish on the exact topic ARN grants only the publish permission needed for SNS. dynamodb:* on a wildcard ARN is overly permissive, granting all DynamoDB actions across all tables — violating least-privilege. sns:* on a wildcard ARN is similarly over-permissive. iam:PassRole is used when a service needs to pass a role to another AWS service; it is not required for a Lambda function to write to DynamoDB or SNS.

Cross-account role assumption requires two-sided trust: (1) The role in Account B must have a trust policy that explicitly allows sts:AssumeRole for the principal in Account A (the EC2 instance profile role ARN). (2) The EC2 instance profile role in Account A must have a permissions policy that includes sts:AssumeRole on the Account B role ARN. Both conditions must be met. The S3 bucket policy in Account B does not need to explicitly allow the Account A role when using cross-account role assumption — once the role in Account B is assumed, the application acts as that Account B role, and the bucket policy only needs to allow the Account B role (or inherit account-level permissions). VPC peering is irrelevant to IAM/STS cross-account role assumption, which operates over the public STS API endpoint. SCPs are only relevant if the accounts are in AWS Organizations and there is a deny SCP in place; they are not required to enable cross-account calls.

Two separate permission grants are needed for this architecture:

[A] The Lambda execution role needs SQS permissions (sqs:ReceiveMessage, sqs:DeleteMessage, sqs:GetQueueAttributes) to poll and process messages. Without these, the Lambda service cannot retrieve messages from the queue on the function's behalf. [C] The SQS service itself (not Lambda) performs the KMS encryption and decryption of the queue's data key. The KMS key policy must grant the SQS service principal (sqs.amazonaws.com) kms:GenerateDataKey (to encrypt new messages) and kms:Decrypt (to decrypt messages for the consumer). Lambda does not call KMS directly for SQS SSE — SQS handles this transparently.

[B] Wrong – Lambda does not directly call KMS to decrypt SQS messages. SQS server-side encryption (SSE-SQS with KMS) is handled by the SQS service internally. Lambda needs SQS API permissions, not KMS permissions, for this use case. [D] Wrong – kms:GenerateDataKey is used for encrypting (producing) data. Lambda is a consumer, not a producer of the encryption. Even if Lambda needed KMS access, it would be Decrypt, not GenerateDataKey. [E] Wrong – sqs:SendMessage allows publishing messages to the queue, not consuming them. Lambda as an SQS consumer needs ReceiveMessage and DeleteMessage. [F] Wrong – kms:CreateGrant is an administrative KMS action used to create grants for delegating key usage; it is not needed for a standard Lambda-SQS processing pattern.

A Cognito User Pool authorizer is the native, no-custom-code integration between API Gateway and Cognito User Pools. API Gateway automatically validates the JWT (ID or access token) against the specified User Pool, including signature verification and expiry checks, with no Lambda function required.

[A] Wrong – A Lambda authorizer can validate JWTs, but requires writing and maintaining custom validation code (fetching JWKS, verifying signature, checking claims), which contradicts the 'least custom code' requirement. [B] Wrong – IAM authorization uses AWS Signature Version 4, not JWTs. Clients would need AWS credentials, not Cognito tokens, making it unsuitable here. [D] Wrong – A resource policy controls which principals (e.g., AWS accounts, VPC endpoints) can invoke an API; it does not perform JWT authentication or interact with Cognito User Pools.

For STS AssumeRole to succeed, three conditions must all be satisfied:

[A] The calling principal's identity-based policy must explicitly Allow sts:AssumeRole for the target role ARN. Without this, the request is implicitly denied at the IAM evaluation stage for the caller. [B] The target role's trust policy (a resource-based policy) must explicitly trust the calling principal (the Lambda execution role ARN) and allow the sts:AssumeRole action. This is the 'who can assume me' definition of the role. [E] If the target account is governed by AWS Organizations, any SCP that applies a Deny on sts:AssumeRole (or restricts STS actions) will block the call, even if both the identity policy and trust policy allow it. SCPs are evaluated as an AND with identity-based policies in the policy evaluation logic.

[C] Wrong – Cross-account AssumeRole is a core feature of AWS STS and does not require same-account placement. The tenant role can be in a completely different AWS account. [D] Wrong – The target role's permission policy defines what the assumed role can DO (its permissions after assumption), not who can assume it. The trust policy governs who can assume the role; the permission policy is irrelevant to the AssumeRole authorization decision. [F] Wrong – Lambda functions do not need to be in a VPC to call AWS APIs, including STS. By default, Lambda functions run in an AWS-managed network with full access to AWS public endpoints. A VPC with NAT Gateway is only needed if the Lambda is inside a VPC and needs outbound internet/AWS API access.