A mobile 311 app needs clients to request flexible field shapes from municipal backends without many bespoke REST round-trips. Which managed API approach fits?
Select an answer to reveal the explanation.
Short Explanation
AppSync’s GraphQL is the custom order window—the 311 app asks for exactly the fields it needs in one trip. S3 listings, SSH tunnels, and CSV spam aren’t flexible mobile API designs.
Full Explanation
AWS AppSync provides a managed GraphQL API that lets the mobile 311 app request flexible field shapes from municipal backends without many bespoke REST round-trips. Clients specify the fields they need in one query, AppSync resolves data from configured sources, and the city avoids proliferating narrow REST endpoints for every screen. That managed GraphQL approach fits mobile flexibility requirements in the stem.
Exposing only raw Amazon S3 bucket listings as the mobile API contract fails by concept because object listings are not a flexible application query API over municipal backends. Requiring the mobile app to open SSH tunnels into each microservice VPC fails as an operational and security anti-pattern for citizen devices—SSH is not a mobile GraphQL/REST API. Replacing the API with nightly CSV email dumps to every resident device fails because batch email files cannot satisfy interactive, flexible field queries from a 311 app.
Exam caveat: Flexible client-defined queries / fewer round-trips → GraphQL via AppSync (managed). Raw S3 listings, SSH tunnels, and CSV dumps are not GraphQL API designs.
Operational check: Confirm AppSync schema matches mobile needs, resolvers hit authorized backends, caching and auth (Cognito/IAM/API keys as designed) are enabled, and clients are not falling back to ad-hoc SSH or bulk CSV. If every screen still needs a new bespoke REST round-trip farm, GraphQL flexibility is unused.