Fine-grained app authorization (Amazon Verified Permissions): SCS-C03 study notes and practice questions
What to know about Fine-grained app authorization (Amazon Verified Permissions) for the SCS-C03 exam, from the Identity and Access Management domain (20% of the exam guide), then 1 free question to test it. Part of the SCS-C03 study guide.
These questions describe an application where access rules are spread across code, or where many services must apply the same rules. The exam expects you to recognize when central, externalized authorization fits, and to keep it separate from IAM, which controls access to AWS resources and APIs.
The facts that decide answers
Policy store holds the Cedar policies and the schema for one application. Applications call the store to make decisions.
Cedar policies use permit and forbid statements that name a principal, an action and a resource, with optional conditions. A forbid overrides any permit.
Policy templates let you write one policy with placeholders and link it to specific principals or resources, which suits rules that differ per user or per object.
IsAuthorized returns Allow or Deny for a request. IsAuthorizedWithToken accepts an ID token, so the service reads the principal and group claims directly.
Identity sources connect a Cognito user pool, so user groups become principal entities that policies can reference.
Decisions are made from your backend, for example in an API Gateway Lambda authorizer or in the service that owns the data.
Rules change without a redeploy. Policy updates take effect in the store, not in the application code.
Scope: Verified Permissions controls what users can do in your application. IAM controls what principals can do with AWS resources.
How to choose
Scenario wording
Pick
Rules such as “managers approve expenses in their own department” shared by several services
Verified Permissions with Cedar policies
User group membership must control application access
Cognito user pool as identity source, with groups as Cedar entities
An API must authorize each request from a signed-in user’s token
IsAuthorizedWithToken
Control who can call AWS APIs or use an AWS resource
IAM, not Verified Permissions
A single simple role check inside one service
Application code is fine
Access rules must be auditable and changed without redeploying
Verified Permissions policy store
Common traps
Using Verified Permissions to control AWS API access. That is IAM’s job.
Treating Cognito groups as enough for resource-level rules. Groups are a principal attribute, and Cedar policies add the resource and condition logic.
Forgetting that forbid overrides permit.
Copying the same rules into each service when the question asks for one central source of truth.
Choosing a custom in-house authorization database when a managed service with a standard policy language fits.
A property management software company runs a multi-tenant app for about 4,000 property managers. Each tenant's data is kept separate, and a user can hold several roles inside one tenant, such as owner, manager, or viewer.
Authorization rules change often as customers ask for new roles, and the team does not want a code deployment for each change. Every request must check whether the user's role in that tenant allows the action on that specific property. No user may see another tenant's properties, even if the application code has a bug.
Which solution meets these requirements?
Choose one answer.
AA. Write the authorization checks as if statements in the application code, with one block for each role and action. Redeploy the service whenever a role or rule changes, and rely on code review to catch tenant scoping mistakes.
BB. Keep Cedar policies in an Amazon Verified Permissions policy store that require the principal's tenant to match the property's tenant. The app calls IsAuthorized on each request, and admins edit policies without a deployment.
CC. Store each user's tenant and roles as Amazon Cognito groups, and let the API Gateway authorizer decide access from those groups. The groups alone can express the tenant, role and property relationships that the app needs.
DD. Create an IAM role for each tenant, and attach IAM policies that allow actions on the property ARNs for the users who belong to that tenant. Use IAM condition keys to match each user's role to the requested action.
Show the answer and explanation
Answer: B
A. Wrong: Code-based checks depend on every developer getting tenant scoping right, which the requirement forbids. Every rule change also needs a deployment, which the team wants to avoid.
B. Right: Correct. Cedar policies can compare tenant and role attributes against each property, and the policy store can change without a code deployment. The check runs on every request, so a query built with the wrong tenant is still denied. Learn more: What is Amazon Verified Permissions? (opens in a new tab)
C. Wrong: Groups carry role membership, but they cannot express that a property belongs to one tenant and that a role applies only to particular properties. The app would still need per-resource logic, so groups alone do not meet the requirement.
D. Wrong: IAM can separate tenants, but it needs roles and policies that grow with each tenant and property, and IAM quotas limit how many roles an account can hold. IAM policies also cannot model a role that applies only to some properties cleanly.
Explanation
Verified Permissions evaluates Cedar policies outside the application code, so rule changes need no deployment, and tenant checks run on every request. Code-based checks rely on every developer, Cognito groups cannot express property ownership, and per-tenant IAM roles do not scale. Only the policy store meets all three constraints.
Want more on Fine-grained app authorization (Amazon Verified Permissions)? The 5 full-length practice sets have 6 more Fine-grained app authorization (Amazon Verified Permissions) questions, 325 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →
Study Fine-grained app authorization (Amazon Verified Permissions)