Transit ops wants an anomaly model on vehicle telemetry. Which approach best layers data-security controls before the feature store is built?
Select an answer to reveal the explanation.
Short Explanation
Lock the safe and leave the jewelry you do not need at home. Transit should shrink what telemetry it keeps and encrypt that smaller set at rest before features are built. Keeping the full raw set even when it's encrypted still hoards data you don't need, TLS alone doesn't cover data at rest, and hashing destroys the data you'll need for features.
Full Explanation
Layering data-security controls before a transit feature store is built means minimizing which vehicle telemetry fields are retained and encrypting that reduced dataset at rest before feature engineering begins. Minimization cuts the volume of GPS, passenger, and maintenance signals that could identify routes, operators, or riders if leaked; encryption at rest then protects the residual corpus on disks, object stores, and backup media used by municipal data science. Doing both before features are derived ensures that derived vectors and aggregations inherit a smaller, already-protected base rather than baking cleartext over-collection into every downstream model. For transit ops, that order matters: once raw traces sit indefinitely in cleartext feature pipelines, every notebook, contractor laptop, and staging bucket becomes a high-value target.
Encrypting the full raw telemetry at rest and minimizing retained fields before building features fails because it encrypts and retains the full, over-collected dataset instead of shrinking it first; a compromised key or credential still exposes every unneeded GPS, passenger, and maintenance field, so storage scope and residual risk stay large rather than reducing to an encrypted, minimized set before features are built. Minimizing retained telemetry fields and protecting the reduced dataset with TLS before building features fails because TLS protects data moving over the network; it does not protect the reduced dataset once it is sitting at rest on disks, object stores, or backups before features are built. Minimizing retained telemetry fields and hashing the reduced dataset at rest before building features fails because hashing is one-way and irreversible, so the telemetry values could not be recovered for feature engineering, and it does not provide reversible at-rest encryption that keeps the reduced source usable while protecting disks, object stores, and backups before features are built.
Exam caveat: Encrypting the full over-collected raw set instead of minimizing first, TLS in transit mistaken for protection at rest, and hashing the reduced set instead of encrypting it at rest are all incomplete for AI data security. Exam stems often tempt candidates to pick a single favorite control; the best answer here layers minimization and at-rest encryption on the raw telemetry before the feature store is built.
Operational check: Confirm telemetry ingestion drops non-essential fields before landing in the feature-store source; verify at-rest encryption (KMS/CMK) on the reduced raw store before feature engineering begins; confirm TLS is used in transit in addition to, not instead of, at-rest encryption; and sample contractor access paths to ensure they use controlled, encrypted repositories rather than ad-hoc CSV transfers for the transit anomaly pipeline.
Prefer to study offline? Printable PDF study book + test engine ($7.50, unofficial). These questions stay free here.