A municipal CRM must export nightly files to partners through AWS Transfer Family. Policy requires encryption in transit for every transfer. Which design choice satisfies that requirement?
Select an answer to reveal the explanation.
Short Explanation
File drops over the open internet need a sealed pipe, not a postcard. FTPS or SFTP on Transfer Family keeps the session encrypted in transit. Plain FTP and public HTTP ignore that rule even if the object sits encrypted in S3.
Full Explanation
When a municipal CRM exports nightly partner files through AWS Transfer Family, encryption in transit means the session protocol itself must protect bytes on the wire. Configuring Transfer Family with FTPS or SFTP satisfies that policy because those protocols negotiate encrypted channels end to end between partner clients and the managed endpoint. For city data exchanges involving citizen or case-related extracts, relying on cleartext file transfer violates both security baselines and typical partner-agreement language even when objects rest encrypted in S3 afterward.
Allowing plain FTP for partner compatibility deliberately disables transit encryption; compatibility is not a substitute for confidentiality. Anonymous HTTP downloads from a public S3 URL similarly expose content without session cryptography and often broaden unintended access. Disabling TLS on the Transfer Family endpoint while encrypting files only at rest confuses encryption domains: at-rest SSE does not protect packets crossing the internet during the transfer.
Exam caveat: map “encryption in transit” to protocol choice (SFTP/FTPS/HTTPS), not to S3 SSE. Distractors often mix storage encryption with transport encryption. Operational check: require FTPS or SFTP only on the Transfer Family server, reject plaintext FTP in the partner runbook, capture Transfer logs showing ciphered sessions, and verify IAM/role access to the destination bucket remains least privilege.