A new Lambda for building-permit webhooks fails because it cannot assume its execution role. The role’s trust policy does not allow the Lambda service. What should be fixed?
Select an answer to reveal the explanation.
Short Explanation
An execution role without lambda.amazonaws.com in the trust policy is a locked door with the right keyring on the wrong hook. Fix the trust relationship so Lambda can assume the role. Runtime swaps and keys in code do not repair trust.
Full Explanation
A Lambda execution role must trust the Lambda service before the function can run with that role. If building-permit webhook invocations fail because the role cannot be assumed, update the trust policy so lambda.amazonaws.com (and the correct account conditions as needed) is allowed to AssumeRole. Permissions policies grant what the role can do after assumption; the trust policy grants who may assume it—both are required.
Attaching AmazonS3FullAccess while ignoring the trust relationship does not fix AssumeRole failures. Storing AWS access keys inside function code to bypass the execution role reintroduces static secrets and fights the Lambda security model. Changing the runtime from Python to Node.js does not make trust policies irrelevant; every runtime still needs a assumable execution role.
Exam caveat: confusing permission policy symptoms with trust policy failures is a common trap—AccessDenied on AWS API calls vs. failures to start because the role cannot be assumed look different in diagnostics. Operational check: fix the trust policy, redeploy/refresh the function configuration, invoke the webhook handler, and confirm the execution role appears in CloudTrail for downstream AWS calls.