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"
    }
}

Vergleiche die Ressource scheduledqueryrules in den AKS-Construction-Templates mit derselben Ressource im eigenständigen logging-template-Deployment. Beginne damit, das eigenständige Bicep-Deployment unter Verwendung der bereitgestellten Abfrage und des Fehlers zu reproduzieren, und verfolge anschließend, wie die Abfrage des Alerts in den beiden Kontexten verarbeitet wird. Als abgeschlossen gilt die Aufgabe, wenn der Alert eigenständig ohne den query-optimization-BadRequest bereitgestellt werden kann.