# Review imagePullPolicy explicitly when changing a Kubernetes image reference > Check the stored pull policy during an image-tag change instead of assuming Kubernetes recomputes its creation-time default. - Canonical URL: https://update.dsesecurity.com/updates/review-imagepullpolicy-explicitly-when-changing-a-kubernetes-image-reference/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-10-30T06:04:30+00:00 - Modified: 2026-10-30T06:05:14+00:00 - Last reviewed by DSE: 2026-10-30 - Resource type: Guide - DSE priority: Advisory - Topics: IT, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Check the stored pull policy during an image-tag change instead of assuming Kubernetes recomputes its creation-time default. ## Potentially affected Kubernetes container definitions whose image reference or pull policy is being changed. ## DSE recommendation Review the effective image reference and imagePullPolicy together before submitting an image update. ## Article Bottom line: Make the desired image pull behavior explicit in the update review. Compare the existing stored policy with the proposed image reference before accepting a tag change as the complete deployment change. ## Source fact: documented behavior The [Images](https://kubernetes.io/docs/concepts/containers/images/) documentation is the primary reference. When imagePullPolicy is omitted, Kubernetes defaults a digest or a non-latest tag to IfNotPresent, and defaults a latest tag or an omitted tag to Always. That default is set when the object is first created; a later image tag or digest change does not automatically revise the stored policy. With Always, the runtime resolves the image through the registry and downloads uncached layers, but it can reuse layers already present locally. ## What the source does not establish This article reviews creation-time defaulting and explicit update intent. It does not approve mutable production tags, promise offline startup or replace registry authorization and credential verification. It excludes the separate runtime-class and image-credential-verification extensions described on the page. ## Applicability questions - Was the stored pull policy explicit or defaulted when this object was created? - Which tag or digest is proposed now? - What pull behavior does the release owner actually require? - Which effective object and runtime observations will demonstrate that requirement? ## DSE recommendation: review the stored policy with the image change DSE recommends a before-and-after record containing the container identity, image reference and effective pull policy. Retrieve the existing managed definition through the approved cluster workflow. Keep the proposed source manifest beside the stored object, rather than treating an omitted field as an instruction whose meaning is obvious. Ask the release owner to state the desired behavior for the update. If the requirement calls for a specific policy, include that field in the reviewed change. Do not introduce a latest tag merely as a convenient way to express a pull requirement. Keep image-content identity and pull behavior as two separately accepted choices. Review the entire controller-managed path used by the application. Identify where the Pod template is maintained and which automation submits it. Compare the resulting container settings after the normal deployment process. Preserve a difference between the submitted configuration and the stored result as evidence for the controller or admission owner to investigate. Keep cache observations precise. Record the image digest and relevant pull events using approved tools, while leaving reusable credentials outside the evidence. Do not count downloaded bytes as the sole proof of the intended policy. Require the application’s normal release checks separately before accepting the updated workload. ## Verification and evidence Proposed verification, not performed: use a disposable workload with an approved test image and a non-latest tag, initially omitting imagePullPolicy. Inspect and retain the actual stored value. Prepare a reviewed image-reference change and write the expected policy before submitting it. Compare that stored result with a separate fixture that explicitly specifies the intended policy. If examining warm-cache behavior is authorized, preserve the cache condition, actual digest, registry access observations and container settings for each case. Keep the test narrowly focused on defaulting and explicit update intent; do not report a complete authorization or offline-recovery result from a successful container start. ## Official references - [Images](https://kubernetes.io/docs/concepts/containers/images/) — Kubernetes. Source review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change. ## Primary reference - Name: Kubernetes — Images - Authority: kubernetes.io - URL: https://kubernetes.io/docs/concepts/containers/images/ - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Review imagePullPolicy explicitly when changing a Kubernetes image reference,” DSE Security, https://update.dsesecurity.com/updates/review-imagepullpolicy-explicitly-when-changing-a-kubernetes-image-reference/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved.