Exams / SAP-C03 / Study guide / Application authentication and authorization (Cognito, Verified Permissions, EKS Pod Identity)
Application authentication and authorization (Cognito, Verified Permissions, EKS Pod Identity): SAP-C03 study notes and practice questions
What to know about Application authentication and authorization (Cognito, Verified Permissions, EKS Pod Identity) for the SAP-C03 exam, from the Security, Compliance, and Governance domain (25% of the exam guide), then 1 free question to test it. Part of the SAP-C03 study guide.
These questions ask how an application signs users in, how it decides what they can do, and how its own code gets AWS credentials without stored keys.
Amazon Cognito
User pools are a user directory and an OAuth 2.0 / OIDC provider. They issue ID, access and refresh tokens (JWTs), support MFA, hosted sign-in (managed login), and federation with social providers, SAML and OIDC IdPs.
Identity pools exchange a token (from a user pool, a social provider, SAML or OIDC) for temporary AWS credentials through an IAM role. Use them when a mobile or browser client must call AWS services such as S3 or DynamoDB directly.
Machine-to-machine: the OAuth 2.0 client credentials grant with resource servers and custom scopes lets services call each other’s APIs.
API Gateway validates user pool tokens with a Cognito authorizer (REST APIs) or a JWT authorizer (HTTP APIs). Lambda authorizers fit custom token logic.
Multi-tenant apps often carry the tenant ID as a custom attribute or token claim, which downstream services use for tenant isolation.
Amazon Verified Permissions
A managed authorization service that evaluates Cedar policies. Your app calls IsAuthorized (or IsAuthorizedWithToken with a Cognito or OIDC token) and gets allow or deny.
Moves permission logic out of application code so it can be reviewed, tested and changed centrally. Supports role-based and attribute-based rules.
For SaaS, a policy store per tenant or a shared store with tenant attributes in the policies.
Workload credentials on EKS
EKS Pod Identity associates an IAM role with a Kubernetes service account through the EKS API. The Pod Identity Agent supplies credentials to pods, with no OIDC provider to set up per cluster, and the same role can be reused across clusters.
IAM roles for service accounts (IRSA) uses the cluster’s OIDC provider and still works; Pod Identity is the simpler choice for new designs.
Never put access keys in container images, environment variables or Kubernetes secrets.
How to choose
Scenario wording
Pick
Customers sign up and sign in, social login, MFA
Cognito user pool
Mobile app uploads straight to S3 with per-user credentials
A hospital group runs a patient portal with a web app and a mobile app. About two million patients sign in, and clinicians sign in through the same portal to view only the patients assigned to them.
The backend is an Amazon API Gateway API with services written by four teams. The rules for who may see which record must be defined once, reviewed by the compliance team, and changed without redeploying the services.
Which solution meets these requirements?
Choose one answer.
AA. Create a Cognito identity pool that gives every signed-in user one IAM role with read access to the patient table, and have each service check the assigned-clinician list in its own code.
BB. Use the API Gateway authorizer to check a shared API key that each app sends, and have each team hard-code the clinician-to-patient mapping in its Lambda functions.
CC. Use an Amazon Cognito user pool for sign-in and an API Gateway JWT authorizer for the tokens. Define the rules as Amazon Verified Permissions policies that each service queries for every record request.
DD. Store each clinician's list of patients in an IAM policy attached to a per-clinician IAM user, and let the mobile app call the API with that user's access keys.
Show the answer and explanation
Answer: C
A. Wrong: A shared role gives every user the same table access, and the rules then live in four services' code. The compliance team cannot review or change the rules in one place.
B. Wrong: An API key identifies an app and does not identify the user, so it cannot enforce per-patient access. Hard-coded mappings also need a redeploy for every change.
C. Right: Correct. The user pool handles sign-in and token issuance, and Verified Permissions holds one policy set that every service calls for authorization decisions. The compliance team can review and change the policies without redeploying the services.
D. Wrong: Patients and clinicians are not IAM users, and per-user access keys in a mobile app are a serious credential risk. This design also cannot scale to two million patients.
Explanation
Cognito handles sign-in and API Gateway checks the token, while Verified Permissions holds the per-record rules in one reviewable place. Shared roles, API keys and per-user IAM keys each leave the rules scattered or the authorization incorrect.
Want more on Application authentication and authorization (Cognito, Verified Permissions, EKS Pod Identity)? The 5 full-length practice sets have 6 more Application authentication and authorization (Cognito, Verified Permissions, EKS Pod Identity) questions, 375 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →
Study Application authentication and authorization (Cognito, Verified Permissions, EKS Pod Identity)