A permitting chatbot's backend service, running as an AWS Lambda function inside the office's own account, needs to call a Bedrock model. The team is deciding between issuing a Bedrock API key and attaching an IAM role to the function for this access. Which choice best fits least-privilege service-to-service access?
Select an answer to reveal the explanation.
Short Explanation
Think of an IAM role like a badge that expires the moment you walk out the building — nothing to lose, nothing to leak. For one AWS service calling another inside the same house, that temporary badge beats a key someone has to remember to lock away. Save the standalone key for guests who don't live there.
Full Explanation
IAM roles issue short-lived, automatically rotated credentials scoped by policy to specific actions, which is the standard mechanism for one AWS-native service calling another inside the same account — a Lambda function's execution role can be scoped to only the Bedrock actions it needs, with no long-lived secret to manage or leak. A standalone API key embedded in environment variables introduces a long-lived credential that has to be protected, rotated, and revoked manually, which is unnecessary risk for traffic that never leaves AWS's own identity boundary. Manual quarterly rotation of that same key is an improvement over never rotating it, but it still leaves a live secret exposed for up to a quarter at a time, compared to a role credential that expires automatically in minutes to hours. Attaching a role with administrator access technically uses the right mechanism but violates least privilege by granting far more than the function needs, which increases blast radius if the function is ever compromised. Scope caveat: this reasoning flips for genuinely external callers — a non-AWS system usually needs a key or a federated credential, not a role it can assume directly. Operational check: review the role's attached policy periodically to confirm it still lists only the Bedrock actions the function actually calls.