A city’s fees microservice must call the ledger microservice with authenticated identity and must not share end-user passwords between services. Which pattern fits?
Select an answer to reveal the explanation.
Short Explanation
Microservices should flash their own work badges—IAM SigV4, mTLS, or a token handoff—not pass around a citizen’s password like a sticky note. Private subnets help, but they are not an identity. Client secrets are not a password stand-in either.
Full Explanation
Microservice-to-microservice calls from fees to ledger should use service identity—IAM SigV4 (for AWS APIs), mTLS, or a token exchange/OAuth client-credentials style flow—so each service authenticates as itself without sharing end-user passwords. That preserves citizen credential boundaries and gives each service independently rotatable credentials and scoped authorization.
Hard-coding a shared citizen password into both services’ environment variables treats a user secret as a machine credential and couples breach domains. Disabling authentication on the ledger API and relying on a private subnet alone is defense-in-depth failure when any path reaches the API. Embedding the Cognito user-pool client secret in both services and passing it as a Bearer “password” misuses a confidential-client secret as a service-to-service user impersonation hack.
Exam caveat: never confuse end-user tokens with service credentials; on DVA-C02, prefer IAM roles for AWS API calls between components on AWS. Operational check: call ledger with valid service credentials and with a citizen password string; confirm only the service identity path succeeds, and rotate the service credential without forcing citizens to reset passwords.