Troubleshooting Scenario Questions

Run in debug mode, then review pipeline logs, then identify the failing task, then check variable values and conditions, then apply a fix and retrigger

Why wrong: Starting with debug mode before reviewing pipeline logs is inefficient because debug produces a massive volume of additional logging that obscures the high-level failure signal you need to locate the failing task. In Azure DevOps, setting system.debug to true increases log verbosity for every task, so without first reviewing the standard logs to know which task requires deeper tracing, you will often spend time wading through irrelevant output. The correct approach is to let the normal logs guide you to the specific task, then enable debug selectively to reduce noise and focus on the actual root cause.

Identify the failing task, then check variable values and conditions, then run in debug mode, then review pipeline logs, then apply a fix and retrigger

Why wrong: Trying to identify the failing task without consulting the pipeline logs first is guesswork, as the log output is the authoritative source for which task emitted an error, warning, or non-zero exit code. Checking variable values before examining logs can also mislead you because the root cause may be a syntax error or missing argument that is only visible in the task output, not in the variable definitions. Additionally, running debug mode before reviewing logs is premature because debug traces are far more useful once you have narrowed the failure to a specific task, whereas doing so upfront floods you with unrelated diagnostic data.

Check variable values and conditions, then apply a fix and retrigger, then review pipeline logs, then identify the failing task, then run in debug mode

Why wrong: This order is fundamentally flawed because it applies a fix before analyzing the logs, meaning you are attempting to resolve an issue without knowing the actual error or root cause—a classic guess-and-test antipattern that can introduce new side effects. After the unvalidated fix and retrigger, the pipeline logs should be reviewed to see whether the fix even addressed the correct failure, but that review happens too late to guide the earlier decisions. Debug mode, which should be used to verify behavior before finalizing the fix, is placed last, making it useless for the initial diagnosis and leaving no verification step before the premature fix.

The SQL Server firewall is blocking the application IP; add a firewall rule.

Why wrong: A SQL Server firewall rule blocks traffic at the network or login layer, producing an immediate connection failure or login error before the application can acquire a connection; it does not cause wait-based timeouts after the connection pool is already in use, so this is not the cause of intermittent timeout symptoms.

The database is experiencing deadlocks; enable read committed snapshot isolation.

Why wrong: Deadlocks are detected by SQL Server's lock manager and immediately terminated with error 1205, not by the application waiting for a connection timeout; enabling read committed snapshot isolation can reduce deadlock occurrences but does not affect connection pool timeout behavior.

The database DTU limit is being exceeded; scale up the service tier.

Why wrong: Exceeding the DTU limit causes Azure SQL Database to throttle or queue queries, typically surfacing as performance degradation or resource-wait errors such as DTU waits, not as connection timeout exceptions from the application; scaling the service tier would not address a connection pool exhaustion issue.

The container image is not publicly accessible.

Why wrong: The container image's accessibility is not the primary issue; while a private registry would need credentials in template (e.g., registryCredentials in siteConfig), the health check failure occurs because App Service cannot verify liveness when healthCheckPath is absent. Even if the image is publicly accessible, the deployment still fails due to missing health probe configuration.

The WEBSITES_ENABLE_APP_SERVICE_STORAGE should be set to 'true'.

Why wrong: Setting WEBSITES_ENABLE_APP_SERVICE_STORAGE to true enables persistent storage mapping (e.g., D:/home) for the container, but it does not affect health check behavior. Health checks rely on the healthCheckPath property and the container's endpoint response, not storage settings, so this option does not address the template's omission.

The template is missing the app setting 'WEBSITES_PORT'.

Why wrong: The WEBSITES_PORT app setting customizes the port the container listens on, but the default is 80; if the container uses a non-default port, it must be specified. However, the question explicitly indicates the health check path is missing, and without healthCheckPath, even a correct port does not enable the required health probe that the deployment expects.

The commit SHA tag is not valid; use 'latest' tag instead.

Why wrong: A Git commit SHA is a valid, immutable image tag that uniquely identifies a build; 'latest' is mutable and not required. The authentication error occurs because the private registry requires credentials, not because the tag format is invalid. The error message would be an authentication failure, not a tag-not-found error.

The image name is incorrect; verify the registry URL.

Why wrong: If the image name or registry URL were incorrect, the client would fail during the resolution phase with a 'not found' style error. The observed error is an authentication error during the pull phase, indicating the image exists but the cluster lacks credentials to access the private registry. Therefore, the problem is not the image name but the missing imagePullSecret.

The 'azure/k8s-deploy' action does not support private registries; use a different action.

Why wrong: The 'azure/k8s-deploy' action does support private registry images as long as the cluster has the required imagePullSecret; it simply does not generate that secret automatically. The action applies manifests but cannot configure Kubernetes authentication for a private registry. The correct fix is to create and reference the secret, not to swap actions.

The query does not include secrets that have no expiry date set.

Why wrong: This is not a flaw for detecting expired secrets because the alert targets secrets with an expiry date; secrets without an expiry date are not relevant to the condition DaysToExpiry and do not affect the identification of already expired ones.

The query only checks secrets that are enabled.

Why wrong: The query does not include any filter on the 'enabled' attribute of the secrets, so it evaluates all secrets in the vault regardless of enabled or disabled state. Therefore, the claim that it only checks enabled secrets is incorrect.

The `limit 10` clause restricts to only 10 secrets, which may miss expired ones.

Why wrong: The `limit 10` operator truncates the result set after the `where DaysToExpiry > 0` clause has already been evaluated, and Kusto filters rows before applying the limit. Because expired secrets have a negative DaysToExpiry, they are removed by that filter and never reach the limit stage, so limiting to 10 rows cannot cause them to be missed. The limit only caps how many non-expired secrets are returned, which might hide expiring-soon secrets but not already expired ones. The actual flaw is the filter itself, which deliberately excludes negative values.