A cloud security engineer is configuring an AWS Lambda function that processes messages from an Amazon SQS queue. The function needs to write results to a DynamoDB table. Which of the following is the SECUREST way to manage the function's credentials?
This follows least privilege and avoids any static credentials.
Why this answer
Option C is correct because AWS Lambda natively supports IAM execution roles, which provide temporary, automatically rotated credentials via the AWS Security Token Service (STS). By attaching an execution role with fine-grained permissions for SQS (e.g., sqs:ReceiveMessage) and DynamoDB (e.g., dynamodb:PutItem), the function never needs to manage long-lived secrets, eliminating the risk of credential leakage or rotation failures.
Exam trap
ISC2 often tests the misconception that storing encrypted credentials in environment variables or using a secrets manager is always the most secure approach, but for AWS-native services, IAM execution roles are the recommended and most secure method because they eliminate the need for any static, long-lived credentials.
How to eliminate wrong answers
Option A is wrong because AWS Secrets Manager is designed for storing secrets like database passwords, but for AWS-native services (SQS, DynamoDB), IAM roles are the securest and simplest approach; using Secrets Manager adds unnecessary complexity and cost without improving security. Option B is wrong because storing credentials as ciphertext in Lambda environment variables still requires the function to have a decryption key (e.g., KMS key) and manage the decryption process, which is less secure than using an IAM role that never exposes static credentials. Option D is wrong because creating an IAM user with long-lived Access Key and Secret Key violates the principle of least privilege and introduces static credentials that must be rotated, encrypted, and managed, whereas an IAM execution role provides temporary credentials that are automatically rotated and scoped to the function's execution.