Security: free practice questions

Correct (A): The Cognito access token is specifically designed to authorize calls to Cognito User Pool API operations (e.g., ChangePassword, UpdateUserAttributes) that require the user to be authenticated. Correct (C): The access token is a JWT that carries OAuth 2.0 scopes and Cognito group memberships; it is the correct token to present to an API Gateway with a Cognito authorizer or a custom OAuth 2.0 resource server to authorize API access. Wrong (B): Identity claims about the user (name, email, sub, etc.) are contained in the ID TOKEN, not the access token. Wrong (D): To obtain temporary AWS credentials from an Identity Pool, the ID token (not the access token) is the correct token to present to the Identity Pool's GetId and GetCredentialsForIdentity calls. Wrong (E): Using a token to get new tokens without re-authentication is the role of the REFRESH TOKEN, not the access token.

Cognito Identity Pools support IAM policy variables that are resolved at credential vending time. By using ${cognito-identity.amazonaws.com:sub} in the IAM permissions policy (e.g., as a condition or resource ARN prefix), you dynamically scope each user's temporary credentials to their specific S3 prefix without needing per-user roles. The trust policy controls who can assume the role, not what the role can access — placing access restrictions there is incorrect. Creating a separate IAM role per user is not scalable and is not a supported Identity Pool feature for this use case. Using aws:PrincipalTag requires attribute mapping and tag propagation through session tags, which is a more complex pattern and not the standard Identity Pool variable approach for this scenario.

For REQUEST type authorizers, the cache key is derived from the Identity Source fields configured by the developer. By including multiple request parameters (e.g., Authorization header plus a user-identifying header or query string), the cache key becomes unique per user, ensuring cached policies are not shared across different callers. Using only the Authorization header (option A) works if each user has a unique token, but the question implies a more explicit user-scoping requirement where combining multiple identity sources is the correct, explicit approach. REQUEST type authorizers do support caching — the claim that they cannot is false. API Gateway does not automatically enforce IP-based conditions from IAM policies in cached responses; the Condition-in-policy approach does not prevent the cached policy from being returned for a different user if the cache key is not unique.

AWS WAF natively supports both SQLi match conditions (via SQL injection match statements or AWS Managed Rules for SQLi) and rate-based rules. You create two separate rules in a Web ACL: (1) a rule with a SQL injection match statement targeting query strings, with Action: Block; and (2) a rate-based rule with a limit of 500 requests per 5-minute window, with Action: Block. Both rules are independent and work simultaneously within the same Web ACL associated with the CloudFront distribution. [A] Wrong – AWS Managed Rule Groups (e.g., AWSManagedRulesSQLiRuleSet) do not include rate-based rules. Managed Rules and rate-based rules are different rule types and must be added separately to the Web ACL. [C] Wrong – AWS WAF does natively support SQL injection detection through SQL injection match statements and managed rule groups. Geo-match rules filter by geography, which is unrelated to SQLi detection. [D] Wrong – While Lambda@Edge can perform custom request filtering, it adds complexity and latency. WAF already provides native SQLi detection without requiring custom code. Combining Lambda@Edge with WAF for this requirement is over-engineered and incorrect — WAF handles both requirements natively.

Option A is correct. An EC2 instance profile assumes a role using the EC2 service principal "ec2.amazonaws.com" with the sts:AssumeRole action. This trust policy statement is placed in the role's trust policy (not the permission policy) and allows the EC2 service to assume the role on behalf of the instance. Option B is incorrect because using the account root ARN as the principal allows any IAM entity in the account to assume the role (if they also have an identity-based policy allowing it), which is overly permissive and not specific to EC2. Option C is incorrect because the "Federated" principal type is used for web identity or SAML federation (e.g., Cognito, Google), not for EC2 service principals; additionally, sts:AssumeRoleWithWebIdentity is for federated web identity, not EC2 instance profiles. Option D is incorrect because lambda.amazonaws.com is the service principal for Lambda functions, not EC2 instances; using this would allow Lambda to assume the role, not EC2.