SCS-C02 Identity and Access Management Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Amazon Cognito identity pools

  Why this is correct

  Amazon Cognito identity pools are purpose-built for granting temporary AWS credentials to mobile app users. When an identity is authenticated (via Cognito User Pools, social providers, or SAML), the identity pool exchanges the user's token for short-lived credentials by assuming an IAM role. These credentials are scoped to that role's permissions and automatically expire, eliminating the need to embed or manage long-term access keys. This is the standard serverless pattern for secure mobile access to AWS APIs.

• ✗

  AWS Key Management Service (KMS)

  Why it's wrong here

  AWS Key Management Service (KMS) is a service for creating and controlling customer master keys used to encrypt and decrypt data. It does not issue, broker, or validate AWS credentials, and it provides no mechanism for authenticating an application user or generating temporary API keys. Using KMS in a mobile app would only help protect data at rest or in transit, not solve the problem of granting API access credentials. Confusing key management with credential management is a common misunderstanding, but KMS has no role in identity federation.

• ✗

  IAM users with long-term access keys

  Why it's wrong here

  Creating IAM users with long-term access keys for mobile app users is insecure and unmanageable. The static key pair would be embedded in the app binary or stored on the device, where it can be extracted, tampered with, and reused indefinitely without per-user revocation. IAM users are intended for server-side workloads or service accounts, not for individual end users of an untrusted mobile client. Best practice is to use temporary credentials with limited scope and expiry, exactly what Cognito identity pools provide.

• ✗

  Amazon CloudFront signed URLs

  Why it's wrong here

  Amazon CloudFront signed URLs are used to restrict access to content that CloudFront serves (e.g., media files or objects in S3) by adding a time-limited URL with an HMAC signature. They are a content-access control mechanism for HTTP requests, not a way to issue or obtain AWS API credentials. Even if your mobile app fetches content via signed URLs, those URLs cannot authenticate API calls to other AWS services. Thus signed URLs solve a different problem and do not grant the temporary AWS credentials the system requires.

Go deeper

Related to this question