Regional partner agencies must upload telemetry into the city’s analytics platform, but security policy forbids exposing raw Amazon S3 buckets publicly on the internet. Which approach best provides private, authenticated ingest access points?
Select an answer to reveal the explanation.
Short Explanation
Partners shouldn’t get a master key to the raw S3 closet. Private API Gateway or VPC interface endpoints give authenticated front doors while the buckets stay off the public internet. Open buckets, wiki secrets, and emailed CSVs with plaintext keys are how incidents start.
Full Explanation
Private Amazon API Gateway endpoints or VPC interface endpoints give regional partner agencies authenticated, private ingest fronts into the city’s analytics platform without exposing raw Amazon S3 buckets on the public internet. Partners call a governed API or PrivateLink path; the city retains encryption, authorization, throttling, and auditing while objects land in private buckets. That pattern matches security policy that forbids public raw-bucket ingest. Disabling all encryption and making the bucket world-readable to simplify partner scripts directly violates confidentiality requirements and creates an indefensible open municipal data store. Publishing the bucket name on a public wiki and relying on security through obscurity provides no real access control once the name leaks. Emailing CSV attachments to a shared mailbox that a nightly cron uploads with a plaintext access key combines insecure credential handling with an unreliable human/email ingest channel. Exam caveat: private APIs still need strong authN/Z (IAM, mutual TLS, or partner Cognito/IAM patterns as designed), and interface endpoints require correct security groups, subnet placement, and private DNS. Operational check: onboard one partner through the private path only, confirm the S3 bucket remains non-public, verify CloudTrail shows authorized API calls, and reject any partner script that attempts direct anonymous S3 PUTs.