Which Actions Does This IAM Policy Allow for a Developer?
A CloudOps engineer must create an IAM policy for a developer who needs access to specific AWS services. Based on the requirements, the CloudOps engineer creates the following policy:
Which actions does this policy allow? (Choose two.)
Community Insight
This item tests exact IAM action-to-API matching; the trap is treating service-level mentions in the policy as broad administrative access to that service.
This SOA-C03 question tests whether you can read an IAM policy's Action elements and map them to AWS API calls. It establishes that the policy permits only ELB describe and Lambda invoke operations, making D and E correct.
The most common wrong answer is B: because the policy mentions Lambda in lambda:InvokeFunction, test-takers assume it also permits creating the Lambda execution role, but iam:CreateRole is a separate action that is not listed.
Community Discussion (1 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
The policy's Allow statement includes the ELB describe action family andlambda:InvokeFunction, with no explicit Deny that would override them. Option D maps directly to the ELB describe action, and option E maps directly to the Lambda invoke action within the policy's Resource scope. IAM evaluates only actions that are listed or matched by a wildcard, so these two API calls are permitted. The answer is therefore D and E, not because the services are broadly accessible but because their exact actions appear in the policy.Why the Other Options Are Wrong
Option A is wrong because creating a Storage Gateway requiresstoragegateway:CreateGateway, which is absent from the Action list. Option B is wrong because iam:CreateRole is a separate IAM permission; lambda:InvokeFunction only executes an existing function and does not confer role-creation rights. Option C is wrong because deleting an SQS queue requires sqs:DeleteQueue, and no SQS delete action is shown. The policy's service mentions do not create implied permissions, so none of these adjacent operations are allowed.Community Comment Notes
Bad_Mat's DE pick matches the action-to-option mapping, and the commenter's aside, "Why my comments is disappears all the time?", offers no contradictory technical argument. Because this is a policy-reading item, the exhibit's Action entries are the authority, not the lone vote record. The community note is therefore useful only as a consistency check, and the decisive evidence remains the explicit ELB describe and Lambda invoke permissions.Official Reference
Exam Strategy
Convert each option to its service-prefix API action before matching: Storage Gateway create, IAM CreateRole, SQS DeleteQueue, ELB DescribeLoadBalancers, Lambda InvokeFunction. Then verify only the exact listed actions are allowed, and remember that an explicit Allow does not imply adjacent permissions.
Frequently Asked Questions
Why does lambda:InvokeFunction not allow creating a Lambda execution role?
Creating a role for Lambda requires iam:CreateRole. InvokeFunction only runs an existing function, so option B is not granted by this policy.
Does elasticloadbalancing:DescribeLoadBalancers allow deleting a load balancer?
No. DescribeLoadBalancers is read-only; deletion needs elasticloadbalancing:DeleteLoadBalancer, which is not in the policy's Action list.
Related Analysis
Practice All SOA-C03 Questions
Access 100 questions with complete answers and detailed explanations.
View Full SOA-C03 Practice Test →