DVA-C02 Troubleshooting and Optimization Practice Question
A developer is using Amazon API Gateway with a Lambda authorizer to control access to APIs. The authorizer is failing with a 500 error. The Lambda function logs show 'User: arn:aws:iam::123456789012:role/MyLambdaRole is not authorized to perform: sts:AssumeRole'. What is the most likely cause?
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
The Lambda function's execution role does not have sts:AssumeRole permission for the target role.
The error message indicates that the Lambda function's execution role (MyLambdaRole) attempted to call sts:AssumeRole but was denied. This occurs when the Lambda function's code tries to assume another IAM role (e.g., to access a resource in another account or service) but the execution role lacks the necessary sts:AssumeRole permission for that target role. Option D correctly identifies this root cause. Option A is incorrect because an invalid policy from the authorizer would generate a different error (e.g., 403 or 401). Option B is incorrect because resource-based policies are for granting cross-account access to the Lambda function, not for assuming roles. Option C is incorrect because while API Gateway needs permission to invoke the Lambda function, a missing invoke permission would cause a different error (e.g., 500 with 'The API Gateway is not authorized to invoke the Lambda function'), not an sts:AssumeRole error.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The Lambda authorizer is not returning a valid policy.
Why it's wrong here
If the Lambda authorizer returns an invalid policy, API Gateway would typically respond with an HTTP 401 (Unauthorized) or 403 (Forbidden) status code, indicating a failure in authentication or authorization. This occurs because the authorizer's output, which dictates access, does not conform to the expected IAM policy structure or denies access explicitly. A 500 error accompanied by an AssumeRole permission denied message points to an issue *within* the Lambda function's execution attempting to interact with another AWS service, not a problem with the authorizer's policy format or its decision.
- ✗
The Lambda function's resource-based policy is missing.
Why it's wrong here
A Lambda function's resource-based policy grants other AWS services or accounts permission to invoke the function itself. For instance, it allows API Gateway to call the Lambda function, or S3 to trigger it upon an object upload. This policy does not govern the permissions that the Lambda function *itself* possesses when it executes; those are defined by its execution role. Therefore, a missing resource-based policy would prevent the Lambda from being invoked, not cause an AssumeRole failure during its execution.
- ✗
The API Gateway does not have permission to invoke the Lambda function.
Why it's wrong here
If API Gateway lacked permission to invoke the Lambda function, the request would fail at the API Gateway stage, likely resulting in a 500 Internal Server Error from API Gateway itself, or a specific error indicating invocation failure, without the Lambda function ever starting execution. The presence of an AssumeRole permission denied error indicates that the Lambda function *was successfully invoked* and began executing its code. The error then occurred when the running Lambda function attempted to perform an action requiring sts:AssumeRole permissions, which it lacked.
- ✓
The Lambda function's execution role does not have sts:AssumeRole permission for the target role.
Why this is correct
The error message "AssumeRole permission denied" directly indicates that the AWS Lambda function, during its execution, attempted to call the AWS Security Token Service (STS) AssumeRole API operation to temporarily assume another IAM role, but its own execution role lacked the necessary sts:AssumeRole permission for that specific target role. The Lambda execution role defines what permissions the function has to interact with other AWS services. Without sts:AssumeRole explicitly granted for the target role in its policy, the function cannot obtain temporary credentials to perform actions under that role's permissions, leading to this specific authorization failure.
Quick reference
Cloud Service Model Comparison
| Model | You Manage | Provider Manages | Examples |
|---|---|---|---|
| IaaS | OS, runtime, apps, data | Hardware, hypervisor, networking | EC2, Azure VMs, GCP Compute Engine |
| PaaS | Apps and data | OS, runtime, middleware, hardware | Elastic Beanstalk, Azure App Service |
| SaaS | Data and settings only | Everything else | Microsoft 365, Salesforce, Workday |
| FaaS / Serverless | Function code only | Infra, scaling, runtime | Lambda, Azure Functions, Cloud Run |
| CaaS | Containers and apps | Kubernetes, OS, hardware | EKS, AKS, GKE |
Go deeper
Related to this question
About these practice questions
Courseiva writes every DVA-C02 question from scratch — 1,135 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This DVA-C02 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the DVA-C02 exam.