A parks department app lets guests browse public park maps without signing in, but write APIs for reservation changes must require authenticated users. How should Cognito identity pools be used?
Select an answer to reveal the explanation.
Short Explanation
Guest browsing is a visitor badge for public maps—tight and read-mostly. Write APIs need a real authenticated identity, not the unauthenticated pool on steroids. Never hand guests broad AWS write.
Full Explanation
Cognito identity pools can vend AWS credentials for both unauthenticated and authenticated identities. Guest browsing of public park maps should use a tightly scoped unauthenticated role limited to read-only map assets. Write APIs that change reservations must require authenticated identities backed by a separate role with write permissions. Keep guest and authenticated power separated so anonymous callers cannot mutate bookings.
Granting the unauthenticated identity role s3:DeleteBucket and dynamodb:* so guests never see auth errors turns anonymous access into full-account damage potential. Disabling Cognito and placing write APIs on the open internet with no identity removes the control entirely. Using the same unauthenticated role for guest map reads and for creating paid reservations lets anonymous callers perform privileged writes.
Exam caveat: unauthenticated identities are still AWS principals—scope them ruthlessly, or skip identity pools for guests if CloudFront/S3 public content alone suffices without AWS credentials in the browser. Operational check: obtain unauthenticated credentials and confirm map reads succeed while reservation writes fail; after sign-in, confirm authenticated credentials can create a reservation and that CloudTrail distinguishes the two roles.