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

Compare the scheduledqueryrules resource in the AKS-Construction templates with the same resource in the standalone logging-template deployment. Start by reproducing the standalone Bicep deployment using the supplied query and error, then trace how the alert's query is handled in each context. Done means the alert can be deployed standalone without the query-optimization BadRequest.