A lab misconfiguration pointed the AWS SDK at a custom DynamoDB endpoint over HTTP, creating a risk of credential and data exposure. What must production clients use?
Select an answer to reveal the explanation.
Short Explanation
Production DynamoDB calls ride HTTPS—period. An HTTP custom endpoint is a cleartext hallway for data and signing material. Lab mistakes teach the rule; do not ship that config to the city’s live stack.
Full Explanation
Production AWS SDK clients must use HTTPS/TLS endpoints for DynamoDB and other services. Sending SigV4-signed traffic in cleartext over HTTP risks exposure of credentials, security tokens, and citizen data to on-path observers—exactly the lab misconfiguration hazard elevated to production. Keep custom endpoint overrides pointing at HTTPS endpoints in real environments and ban cleartext service URLs in deploy configs.
Preferring HTTP in production to avoid TLS handshake latency is an unacceptable trade for municipal systems. Custom endpoints are not required to be HTTP; HTTPS works for VPC endpoints and public endpoints alike. Disabling signing and placing access keys in query strings over HTTP compounds multiple anti-patterns.
Exam caveat: local stacks sometimes use HTTP endpoints; production configuration must not inherit those overrides from shared .env files. Operational check: print the resolved DynamoDB endpoint in a staging task, assert it begins with https://, attempt to deploy an http:// override and fail the pipeline config check, and confirm traffic from the app uses TLS in a packet capture or VPC flow/TLS inspection equivalent. For municipal workloads, document the chosen pattern in the runbook so the next on-call engineer applies the same control instead of inventing a weaker shortcut under pressure.