A utility analytics warehouse on Amazon Redshift must protect data at rest and require encrypted client connections. What should the architect enable?
Select an answer to reveal the explanation.
Short Explanation
Warehouse data needs both a locked disk and a locked wire. Turn on Redshift encryption at rest and insist on SSL for clients. Renaming columns or opening the door wide is not a security control.
Full Explanation
A utility analytics warehouse on Amazon Redshift should protect data both at rest and in transit. Enabling cluster encryption at rest (typically with KMS) and requiring SSL for database connections meets that dual requirement: disk and snapshot material stay encrypted, while JDBC/ODBC clients negotiate TLS so meter and utility fields are not sent in cleartext across the network. For regulated utility analytics in a municipal context, both controls are usually mandatory together.
Disabling cluster encryption and allowing only plaintext JDBC for speed trades compliance for marginal convenience and fails the stated requirement. Exposing the cluster publicly without security groups because users are “trusted” removes network boundary defense and is unrelated to satisfying encryption settings. Relying solely on column renaming to obscure sensitive fields is not encryption—security through renaming is not a control.
Exam caveat: Redshift encryption at rest is often selected at launch (with known limitations around enabling later depending on configuration era); always pair with require_ssl parameter groups/settings. Operational check: verify the cluster shows encrypted storage, set require_ssl, attempt a non-SSL connection and confirm rejection, and ensure subnet groups keep the warehouse off the public internet.