Who's Swimming In My Pool?
Which AWS service provides a managed user directory with sign-up, sign-in, and user authentication features for web and mobile apps?
A. AWS Directory Service
B. Amazon Cognito User Pools
C. AWS Identity and Access Management (IAM) Users
D. Amazon CloudWatch
Answer: B
Explanation: Amazon Cognito User Pools offer a user directory and handles user registration and authentication (including verifying emails/phone, password resets, etc.). It is designed for authenticating users of your applications. AWS Directory Service is for integrating with corporate Active Directory, and IAM users are for AWS resource access (not scalable for app user sign-in).
Which AWS service is specifically used to obtain temporary security credentials (Access Key ID, Secret Access Key, and Session Token) for AWS resources?
A. Amazon Cognito User Pool
B. AWS Security Token Service (STS)
C. Amazon CloudWatch
D. AWS Key Management Service (KMS)
Answer: B
Explanation: AWS STS (Security Token Service) issues short-lived credentials upon request. For example, the AssumeRole API of STS returns a temporary Access Key, Secret Key, and Session Token that expire after a set time. Cognito User Pools are for user authentication (they issue JWT tokens, not AWS API keys), CloudWatch is for logging/monitoring, and KMS manages encryption keys.
A developer wants an EC2 instance to access an S3 bucket without embedding any AWS credentials on the instance. What is the recommended solution?
A. Attach an IAM Role to the EC2 instance with a policy allowing S3 access.
B. Store an IAM user’s access key and secret on the EC2 instance and set them as environment variables.
C. Use the EC2 instance’s IP address in an S3 bucket policy to bypass credentials.
D. Manually generate temporary credentials and place them on the instance at launch.
Answer: A
Explanation: The secure, recommended way is to use an IAM Role assigned to the EC2 instance (via an instance profile). The EC2 instance metadata service will provide temporary credentials to the instance, which the AWS SDK or CLI on that EC2 can use to access S3. This avoids static credentials. The other options either involve hard-coding credentials (bad practice) or are not feasible (IP address in a bucket policy doesn’t grant permissions, and manually managing temp creds is error-prone and not scalable).
What is the main purpose of an Amazon Cognito Identity Pool (Federated Identities)?
A. To store user account information and handle sign-ups and sign-ins for your applications.
B. To manage user credentials for logging in to the AWS Management Console.
C. To exchange identity provider tokens (from Cognito User Pools or social logins) for temporary AWS credentials.
D. To synchronize application data across devices for users (data synchronization).
Answer: C
Explanation: Amazon Cognito Identity Pools are used for authorization to AWS resources. After a user is authenticated (for example, via a Cognito User Pool, or Google/Facebook, etc.), the Identity Pool will obtain temporary AWS credentials (via STS) associated with an IAM role. These credentials allow the app to access AWS services on the user’s behalf. Identity Pools do not manage the user directory itself (that’s what User Pools do). And while older Cognito had a sync feature, that’s deprecated (and not directly related to Identity Pools’ core purpose).
Which of these is NOT a type of IAM identity-based policy?
A. AWS Managed Policy
B. Customer Managed Policy
C. Inline Policy
D. Security Group Policy
Answer: D
Explanation: In IAM, the identity-based policy types are: AWS Managed (created and managed by AWS), Customer Managed (created by you in your account), and Inline (policy directly attached to a single user/group/role). "Security Group policy" is not an IAM concept – security groups are related to network traffic, not IAM permissions. (Similarly, other distractors like “network ACL policy” or “group policy” are not distinct IAM policy types.)
Which of the following is NOT a feature of Amazon Cognito User Pools?
A. Built-in support for social logins (Facebook, Google, etc.) for user sign-in
B. Ability to enforce multi-factor authentication (MFA) for added security
C. Issuing temporary AWS access credentials to users for AWS resource access
D. Providing a hosted web UI for user sign-up and sign-in flows
Answer: C
Explanation: Cognito User Pools manage user authentication and provide JSON Web Tokens (ID and Access tokens) upon login, but do not directly issue AWS credentials. To get AWS access keys/token after user login, you integrate with a Cognito Identity Pool (federated identities). All other options (social login integration, MFA, hosted UI) are true features of user pools.
What is an AWS best practice for managing AWS access keys in application code?
A. Embed long-lived AWS access keys and secrets directly in your application code for fast access.
B. Use the AWS root account credentials for all programmatic access to avoid permission issues.
C. Use IAM roles or STS to provide temporary credentials to the application, rather than hardcoding keys.
D. Share one IAM user's access key among all applications to simplify key management.
Answer: C
Explanation: Never hard-code long-term credentials in your application. AWS best practices advise using IAM Roles (for AWS resources like EC2, Lambda, ECS tasks, etc.) or AWS STS to generate temporary, limited-privilege credentials for applications. This minimizes exposure from key leakage and allows automatic key rotation. Options A, B, and D are insecure: using root credentials or shared static keys is strongly discouraged due to the risk and lack of fine-grained control.
In an IAM role definition, what specifies who is allowed to assume that role?
A. The IAM permission policy attached to the role
B. The role’s trust policy (the “AssumeRole” policy)
C. The instance profile associated with the role
D. Tags on the role indicating trusted accounts
Answer: B
Explanation: Every IAM role has a trust policy (also called an assume role policy document) which lists the principals that are allowed to assume the role. This is where you specify either AWS services (e.g., EC2, Lambda) or other AWS accounts/ARNs that can use the role. The role’s permission policy, by contrast, defines what actions the role can perform once assumed. Instance profiles are just a mechanism to attach roles to EC2, and tags don’t grant trust by themselves.
In a Cognito Identity Pool, you typically configure:
A. An IAM role for authenticated users and a separate IAM role for unauthenticated (guest) users.
B. A distinct identity pool for each user.
C. A single static IAM user that all app users share.
D. No IAM roles at all, since Cognito Identity Pools don’t use IAM.
Answer: A
Explanation: A Cognito Identity Pool often defines two IAM roles: one for authenticated identities (users who have logged in via some identity provider and received an identity), and one for unauthenticated identities (guest users, if you allow guest access). Cognito will switch between these based on whether the user is signed in. You would not create an identity pool per user (the pool holds many users' identities), and Identity Pools absolutely do use IAM roles under the hood. Sharing one static IAM user’s credentials for all users is not how Cognito is designed – instead it gives each user a federated identity and ephemeral creds.
You need to give 15 different IAM users the exact same set of custom permissions. What is the best way to implement this with minimal maintenance overhead?
A. Create a Customer Managed Policy with the required permissions and attach it to all 15 users.
B. Create an inline policy on one user and copy/paste it into the other 14 users.
C. Use an AWS Managed Policy, even if it has extra permissions, to cover all needs.
D. Make all 15 users members of an IAM group but don’t attach any policy (groups by themselves don’t grant permissions).
Answer: A
Explanation: Customer Managed Policies are ideal for this scenario. You can define the exact permissions once and attach that single policy to multiple IAM principals (users, in this case). This is easier to maintain – if the policy needs updating, you update it in one place. Option B (inline on each user) means 15 separate policies to manage (error-prone and not scalable). An AWS Managed Policy might not fit your exact needs or could grant more than necessary; it’s best to create a least-privilege custom policy. Groups (with a policy attached) could also solve the scenario by attaching a managed policy to a group – but option D as stated has no policy, so it wouldn’t grant anything.
After a successful login to a Cognito User Pool, which token contains the user's identity claims (like username or email) that the application can use to identify the user?
A. Access Token
B. ID Token
C. Refresh Token
D. AWS STS Session Token
Answer: B
Explanation: Amazon Cognito User Pools follow the OpenID Connect standard, returning an ID Token (JWT) that contains user identity claims (name, email, etc.), an Access Token (for authorizing access to user pool-protected APIs or resources), and a Refresh Token (to get new tokens when the current ones expire). The ID Token is meant to share user identity info with your application (e.g., to personalize the UI), whereas the Access Token is used for authorization checks (it contains scopes or groups but not all profile attributes).
AWS STS temporary credentials consist of three components. Which of the following lists all the components returned by STS (for example, when calling AssumeRole)?
A. Access Key ID, Secret Access Key, and Session Token
B. Username, Password, and Multi-Factor Code
C. Key Pair ID, Private Key File, and X.509 Certificate
D. Account ID, User ARN, and Security Token Service URL
Answer: A
Explanation: When you assume a role or get session credentials from STS, you receive an Access Key ID, a Secret Access Key, and a Session Token. These work together as a set. The Access Key ID and Secret Key function like a normal credential pair, and the Session Token is a special token that must be included in API requests to prove the temporary credentials are valid. (Usernames/passwords or key pairs are not what STS provides; those are different auth mechanisms.)
Account A wants to let a user from Account B assume a role in Account A. What must Account A do to allow this cross-account access?
A. Share the AWS root user credentials from Account A with the user in Account B.
B. Enable S3 cross-account access in the AWS console (this is service-specific and not how roles are granted).
C. Add Account B (or the user’s ARN in Account B) as a trusted principal in the role’s trust policy in Account A.
D. Nothing – IAM roles are global and any user in any account can assume a role if they know the ARN.
Answer: C
Explanation: To allow an IAM principal in Account B to assume a role in Account A, you must update the role’s trust policy in Account A to trust that principal. Typically, this is done by specifying Account B’s account ID (or a specific user/role ARN in Account B) as a principal in the trust policy. Additionally, the user in Account B needs IAM permission to call STS:AssumeRole on that role. Sharing root credentials is insecure and not at all required. Simply “enabling” cross-account access in a service console is not how IAM roles work; it’s done via roles and policies. And IAM roles are not automatically assumable by everyone – only principals explicitly listed (or those that match a condition in the trust policy) can assume them.
Which scenario is an example of Web Identity Federation using Cognito Identity Pools?
A. An EC2 instance assumes a role in another AWS account to access a database.
B. A user signs in with their Facebook account to your app, and the app then gets AWS credentials via a Cognito Identity Pool to access an S3 bucket.
C. Using AWS Single Sign-On (AWS SSO) for central workforce login to the AWS Management Console.
D. A user logs in to an application with an IAM user name and password.
Answer: B
Explanation: Web Identity Federation allows users who authenticate with an external identity provider (e.g., Facebook, Google, Amazon, or any OpenID Connect provider) to obtain temporary AWS credentials. Cognito Identity Pools facilitate this by trusting the external provider’s token and then calling STS to get credentials mapped to an IAM role. In this case, the user uses Facebook login, Cognito Identity Pool trades the Facebook OAuth token for AWS credentials tied to an IAM role (with, say, S3 access). EC2 assuming a role in another account is cross-account IAM (not web identity federation). AWS SSO is for enterprise SSO, and IAM user login is just a direct IAM authentication (not federating a web identity).
What is one advantage of using managed IAM policies (either AWS-managed or customer-managed) instead of inline policies?
A. Managed policies are automatically optimized for least privilege.
B. Managed policies can be reused and attached to multiple IAM users, roles, or groups.
C. Managed policies override other policies, giving them higher precedence.
D. Managed policies are hidden from IAM users, enhancing security through obscurity.
Answer: B
Explanation: The key advantage of a managed policy is reusability – you create it once (or use an AWS-provided one) and then attach it to many identities as needed. This also allows central updates. Inline policies, by contrast, are one-to-one attached to a single identity and cannot be easily reused or centrally managed. Option A is wrong because AWS doesn’t auto-optimize your policies; you must design them. All policies (inline or managed) have equal evaluation weight (no priority for managed vs inline, aside from explicit denies). And managed policies are visible in your account just like other policies (no “security through obscurity” there).
A developer wants to run custom validation logic every time a user attempts to sign in to the Cognito User Pool (for example, checking a 3rd-party risk score before allowing login). Which Cognito feature should be used?
A. Amazon EventBridge rule triggered by Cognito
B. Amazon Cognito Advanced Security
C. Amazon SNS notification from Cognito
D. Cognito User Pool Lambda Trigger (e.g., a Pre-Authentication trigger)
Answer: D
Explanation: Cognito User Pools support Lambda Triggers that execute your custom code at various stages of the authentication lifecycle. In this case, a Pre-Authentication Lambda trigger can be used to run custom validation before the user is allowed to sign in. (Other triggers exist for pre sign-up, post confirmation, token generation, etc.) EventBridge or SNS are not direct mechanisms for inline auth validation, and “Advanced Security” in Cognito refers to adaptive risk-based authentication, not arbitrary custom checks.
An IAM user must use multi-factor authentication (MFA) to access AWS API calls programmatically. After the user supplies the MFA code, which STS API call should be used to get temporary credentials that reflect the MFA?
A. AssumeRole
B. GetSessionToken
C. AssumeRoleWithWebIdentity
D. GetCallerIdentity
Answer: B
Explanation: An IAM user can call GetSessionToken (part of STS) with their long-term credentials and an MFA token code to get temporary session credentials. The returned session’s credentials will be valid only if MFA was used, satisfying any policies that require MFA (condition aws:MultiFactorAuthPresent). AssumeRole is typically used to assume IAM roles (and can include MFA if the role’s trust policy demands it, but for a direct IAM user session with MFA, GetSessionToken is the appropriate call). AssumeRoleWithWebIdentity is for federating via web identity providers, and GetCallerIdentity just returns details about the current credentials – it doesn’t issue new ones.
You want to allow a third-party external service (outside of AWS) to assume an IAM role in your account, but only that service (and not anyone else) should be able to use it. What extra configuration should you use?
A. Require multi-factor authentication (MFA) for the role.
B. Use an IAM access key instead of a role for third-party access.
C. Limit the role to the third party’s IP range.
D. Include a unique External ID in the role’s trust policy and have the third party use that External ID when assuming the role.
Answer: D
Explanation: An External ID is a string value that you, as the account owner, add as a condition in the role’s trust policy, and the third party must supply that same External ID in its AssumeRole API call. This ensures that only someone explicitly knowing the External ID (presumably the trusted third-party service) can assume the role, mitigating the “confused deputy” problem. MFA can be used for internal users, but a third-party service won’t have an MFA device in your account. IP address conditions might be used in some scenarios but are less reliable and not unique to the third party. Using access keys (long-term credentials) isn’t as secure or controllable as using a role with an external ID.
When Cognito Identity Pools grant AWS credentials based on an external identity (like a user logging in with Google or a Cognito User Pool), which STS API is used behind the scenes to obtain those temporary credentials?
A. STS AssumeRole
B. STS GetFederationToken
C. STS AssumeRoleWithSAML
D. STS AssumeRoleWithWebIdentity
Answer: D
Explanation: Cognito Identity Pools use STS under the hood. For public identity providers (OIDC/OAuth2 like Google, Facebook, or even Cognito User Pool tokens), the Identity Pool uses the AssumeRoleWithWebIdentity API to trade the IdP's token for AWS credentials associated with the appropriate IAM role. (If using Cognito User Pools, Cognito acts as an OpenID Connect provider and similarly the call is AssumeRoleWithWebIdentity using the user pool’s ID token). GetFederationToken is an older method for custom federation using IAM users, and AssumeRole is used when you already have AWS credentials and just need to assume a role (not directly with a web ID token).
You have an IAM role that should have a policy exclusively for that role’s use, and you want the policy to be deleted if the role is deleted. What kind of policy would you use?
A. An inline policy on the IAM role.
B. A customer managed policy attached to the role.
C. An AWS managed policy.
D. A service control policy (SCP).
Answer: A
Explanation: An inline policy is embedded directly in an IAM principal (user, group, or role) and maintains a strict one-to-one relationship. If you delete that role, the inline policy goes with it automatically. This makes sense for exclusive, principle-specific rules that shouldn’t outlive the principal. A customer managed policy is a separate entity in your account – if you detach it or delete the role, that policy remains in the account (or could still be attached elsewhere). AWS managed policies are general-purpose and not tied to a single role. SCPs are used at the organization level (in AWS Organizations) and don’t attach to individual roles/users.
An application needs to categorize users into "Admins" and "Members" within a Cognito User Pool and have this reflected in their tokens. What feature of Cognito User Pools can help achieve this?
A. Use separate User Pools for admins and members
B. Create Cognito User Pool Groups (e.g., an "Admins" group and a "Members" group)
C. Assign IAM roles directly to individual users in the User Pool
D. Tag users with AWS Organization units
Answer: B
Explanation: User Pool Groups in Cognito allow you to create group designations (such as "Admin" or "Member") and assign users to them. Group membership can then appear in the user's token (e.g., in the cognito:groups claim of the ID/Access token). This is useful for application logic or for mapping to IAM roles when using an Identity Pool. You cannot attach IAM roles directly inside a user pool; instead, you'd use an Identity Pool to map Cognito user groups to IAM roles if AWS resource access is needed.
By default, how long are AWS STS AssumeRole credentials valid, and what is the maximum duration you can configure for an STS role session?
A. 1 hour by default; up to 12 hours maximum
B. 1 hour by default; up to 24 hours maximum
C. 15 minutes by default; up to 1 hour maximum
D. 12 hours by default; up to 12 hours maximum
Answer: A
Explanation: The default session duration for STS AssumeRole credentials is 3600 seconds (1 hour). AWS allows you to extend the maximum role session duration up to 12 hours (43200 seconds), if you explicitly configure the role to allow it and use the appropriate API parameter. (Note: Some scenarios like role chaining or certain console sessions might be limited to 1 hour even if a longer duration is requested.) Options B and D are incorrect (24h is not allowed for STS, 12h is the cap, and the default is 1h, not 12h), and C is incorrect (15 min is the minimum, not the default).
An application running on EC2 in Account A needs to read data from an S3 bucket in Account B. What is the most secure way to allow this access?
A. Create an IAM user in Account B with permissions to the bucket, and distribute its access key to the EC2 application.
B. Rely on the instance’s IAM role in Account A, since roles automatically work across accounts.
C. In Account B, create an IAM role that grants access to the S3 bucket and trusts Account A (or the EC2’s role). Then have the application assume that role via STS.
D. Make the S3 bucket publicly readable while the application is running.
Answer: C
Explanation: The safest approach is to use cross-account IAM roles. In Account B, you create a role with a policy permitting access to the bucket, and set its trust policy to allow Account A (or specifically the ARN of the EC2’s role in Account A) to assume it. The EC2 instance (using its instance role credentials) can then call STS:AssumeRole to get temporary creds from Account B’s role and access the bucket. This avoids sharing long-term credentials (Option A is not secure or scalable). Option B is incorrect because having a role in Account A doesn’t automatically grant cross-account access — the role must be permitted by Account B. Option D (public bucket) is obviously not secure for sensitive data.
A developer wants users in a Cognito User Pool who belong to an "Admins" group to receive a different IAM role via a Cognito Identity Pool than regular users. How can this be accomplished?
A. It’s not possible to assign different IAM roles to users of the same identity pool.
B. Use multiple Cognito Identity Pools, one for admin users and one for regular users.
C. Configure Role Mapping in the Cognito Identity Pool to map users to different IAM roles based on their User Pool group membership (e.g., map "Admins" group to an admin IAM role).
D. After getting credentials from the identity pool, make the application call STS:SwitchRole to change the role if the user is an admin.
Answer: C
Explanation: Cognito Identity Pools support Role Mapping rules. You can set up rules to choose an IAM role for the user based on information from the identity provider token – for example, if the user’s Cognito User Pool ID token contains a group claim "Admins", the identity pool can assign them to an IAM role with elevated permissions. This allows a single identity pool to grant different levels of access to different users transparently. You do not need multiple identity pools for this scenario, and option D (application switching roles manually) is more complicated and not the intended solution when Cognito can do it automatically.
If one IAM policy attached to a user explicitly denies an action but another policy attached to the same user allows it, what is the result when that user attempts the action?
A. The policies cancel each other out and the default deny applies.
B. The action is denied because an explicit deny always overrides any allow.
C. The allow policy takes precedence since it’s a direct attachment.
D. IAM will allow the action but flag a warning in CloudTrail.
Answer: B
Explanation: Explicit deny trumps allow in AWS’s policy evaluation logic. If any policy (identity-based or resource-based, SCP, etc.) explicitly denies a request, the request will be denied, even if other policies grant access. AWS IAM policies are evaluated by first checking if there’s an explicit deny; if not, then if there’s any allow (otherwise default deny). There is no merging that “cancels out” – an allow cannot override a deny. This is a fundamental principle of IAM policy evaluation.