Issue with a Log Analytics Data Cap Breach Alert

I am trying to setup a scheduled query alert from the AKS-Construction repo, and have run into some odd behavior. Apparently, the alert can be setup from the AKS-Construction templates, but not from a standalone deployment. I am trying to move the alert into my logging templates as it isn't really AKS related.

https://github.com/Azure/AKS-Construction/issues/559

resource Daily_data_cap_breached_for_workspace_logworkspacename_CIQ_1 'microsoft.insights/scheduledqueryrules@2022-06-15' = {
  name: 'Daily data cap breached for workspace ${resLogAnalyticsWorkspace.name} CIQ-1'
  location: parAutomationAccountLocation
  properties: {
    displayName: 'Daily data cap breached for workspace ${resLogAnalyticsWorkspace.name} CIQ-1'
    description: 'This alert monitors daily data cap defined on a workspace and fires when the daily data cap is breached.'
    severity: 1
    enabled: metricAlertsEnabled
    evaluationFrequency: evalFrequency
    scopes: [
      resLogAnalyticsWorkspace.id
    ]
    windowSize: windowSize
    autoMitigate: false
    criteria: {
      allOf: [
        {
          query: '_LogOperation | where Operation == "Data collection Status" | where Detail contains "OverQuota"'
          timeAggregation: 'Count'
          operator: 'GreaterThan'
          threshold: 0
          failingPeriods: {
            numberOfEvaluationPeriods: 1
            minFailingPeriodsToAlert: 1
          }
        }
      ]
    }
    muteActionsDuration: 'P1D'
  }
}

throws the following exception from a standalone bicep deployment

{
    "status": "Failed",
    "error": {
        "code": "BadRequest",
        "message": "Couldn't optimize the query because it doesn't contain the table Operation explicitly. Please add the table to the query explicitly and try again"
    }
}

Compara el recurso scheduledqueryrules en las plantillas de AKS-Construction con el mismo recurso en el deployment independiente de logging-template. Empieza reproduciendo el deployment independiente de Bicep usando la consulta y el error proporcionados, y después sigue cómo se gestiona la consulta de la alerta en cada contexto. Se considera terminado cuando la alerta se puede desplegar de forma independiente sin el BadRequest de query-optimization.