Conservation telemetry lands in an Eventhouse as raw sensor rows with separate temperature-in-Celsius and humidity-percentage fields. Before the data is queried by the visualization team, an engineer wants to compute and store a derived risk-score column on each row as it's processed. Which KQL capability is designed for adding a computed column like this?
Select an answer to reveal the explanation.
Short Explanation
Think of extend like a clerk adding a calculated field to the margin of an existing ledger page — the original entries stay put, but now there's a new column showing the number that matters for the report. That's what extend does to each row in KQL.
Full Explanation
KQL's extend operator computes a new column from an expression over a row's existing fields — here, combining temperature and humidity into a derived risk score — and appends it to the result set (or, via an update policy, to the stored table) without disturbing the original columns. That's precisely the “add a computed column per row” pattern the scenario calls for. Dropping the raw fields removes the very inputs the risk-score calculation depends on and doesn't add anything; it's a cleanup action, not a transformation one. GROUP BY is T-SQL syntax, not KQL, and even conceptually it collapses multiple rows into aggregates, which is a different operation from computing one new value per existing row. A OneLake shortcut only creates a reference to data that already exists somewhere; it has no computational role and can't derive a new column on its own. Before wiring extend into an ongoing ingestion path, check whether the transformation should run as a KQL update policy applied automatically to new rows, rather than as a one-off query against historical data.