After migrating departmental file shares to Amazon S3, who must apply correct access policies on the buckets?
Select an answer to reveal the explanation.
Short Explanation
Moving files to S3 doesn't hand your permissions problem to AWS. You still set bucket and object access policies, and you don't leave resident data wide open just because it changed storage.
Full Explanation
After migrating data to AWS storage such as Amazon S3, data access policies remain the city's responsibility. Changing the storage building does not invent a receptionist who somehow knows your former file-share permissions. The correct position is that the city must apply correct bucket and object access policies after migration. The choice saying AWS automatically grants public access to every migrated bucket for convenience is wrong; AWS does not do that, and public access would be a serious misconfiguration for resident records. The choice saying only AWS Artifact can attach bucket policies on behalf of customers is wrong; AWS Artifact is not the mechanism that attaches bucket policies on behalf of customers as a substitute for city governance. The choice saying access policies become unnecessary once objects leave on-premises file servers is wrong; access policies do not become unnecessary merely because objects left on-premises file servers. The wrong choices fail by celebrating automatic public access, by misusing Artifact as a policy attachment robot, or by claiming migration deletes the need for access control. Exam caveat: migration projects often fail audits when buckets are left open "temporarily"; CLF-level questions emphasize that customer policy ownership continues after lift-and-shift. Operational check: apply least-privilege bucket policies and IAM controls, use S3 Block Public Access where appropriate, enable access logging and encryption, inventory migrated prefixes for overly broad grants before go-live, and re-validate policies after each application cutover.