A municipal Amazon OpenSearch Service domain stores citizen feedback and must enable encryption at rest and node-to-node encryption. Which action best applies those data security controls on the service?
Select an answer to reveal the explanation.
Short Explanation
Flip on the domain’s own locks: encryption at rest for disks and node-to-node encryption for chatter between nodes. A fancy “encrypted-” nameplate without those settings is just paint.
Full Explanation
A municipal Amazon OpenSearch Service domain storing citizen feedback should enable encryption at rest and node-to-node encryption on the domain itself so data is protected on disk and traffic between nodes is encrypted in transit inside the service mesh. Those domain settings are the service-native controls Associate-level candidates are expected to select—renaming resources or exporting cleartext does not substitute for flipping the domain encryption features during create/update (as supported).
Disabling domain encryption features and placing the domain in a public subnet with an open security group fails confidentiality and network exposure simultaneously. Relying only on renaming the domain to encrypted-feedback without changing settings fails because names are not cryptographic controls. Exporting all feedback to unencrypted CSV on a public website nightly inverts the security goal and creates a larger breach surface.
Exam caveat: encryption at rest and node-to-node encryption are distinct toggles from HTTPS client-to-domain encryption; design all layers, and remember some settings are selected at domain creation time depending on configuration options. Operational check: inspect the domain configuration for both encryption settings enabled, confirm clients use HTTPS/TLS to the endpoint, verify the domain SG is not 0.0.0.0/0 to the OpenSearch ports, and sample that fine-grained access control or IAM policies restrict index reads appropriately.