# Azure Storage Account Missing Lifecycle Policy

> Azure storage accounts without a blob lifecycle policy are detected through the discoverer's lifecycle_policy_set flag, but ZopNight currently abstains on every one: pricing the saving needs a per-age capacity split no producer emits yet, and the rule refuses to ship a $0 or fabricated figure.

Source: https://zop.dev/integrations/azure/recommendations/azure-storage-account-missing-lifecycle-policy
Updated: 2026-08-19

---

## A detection that works, a recommendation that waits

The gate for this rule is real and already wired: the discoverer probes each storage account's management policies and stamps `lifecycle_policy_set`: "true" when a policy is confirmed, "false" when the API returns a 404, and nothing at all on a transient error, so an unknown state never masquerades as a missing policy. But today the rule abstains unconditionally even when the flag says "false". If you never see this finding in ZopNight, that is why. The silence is deliberate, not a bug.

## Check for a policy yourself

```bash
az storage account management-policy show \
  --account-name <account> -g <rg>
```

An error saying the policy does not exist is exactly the condition the discoverer records as "false".

## Why pricing a lifecycle policy is genuinely hard

The saving from adding a lifecycle policy is the capacity of blobs old enough to transition, multiplied by the rate difference between Hot and Cool or Archive. The hard input is the age split: knowing how many GB of Hot data have gone untouched long enough for a rule to move them. Azure Monitor exposes total capacity, not an age histogram, so no producer today can supply that number. ZopNight's directive for cost-driven categories is strict: carry a real, data-backed dollar figure or return nothing. A $0 recommendation would also be dropped by the minimum-savings filter before anyone saw it.

## The double-count trap the abstention avoids

Two sibling rules already price account-level tier moves: the Hot-to-Cool retier delta computed by the aggregator backs both the account tier-flip rule (RC-1325) and the low-traffic retier rule (RC-274). Reusing that same delta as a "lifecycle saving" would count identical gigabytes twice across two open recommendations. RC-1325's design explicitly depends on this rule contributing zero.

## Worth doing anyway

Waiting for a priced recommendation is not a reason to run without a policy. Age-based transitions for logs, backups, and build output, plus delete-after rules for data with a known retention, are cheap to write and take effect within about 24 hours of being set. The rule still declares 30-day `StorageUsedCapacity` and `StorageEgress` series as supporting evidence, readable under Monitoring Reader, so the pieces are in place for the day the age-split producer lands.