4. Image Engineering and Secure Build Practices

Introduction and Context

A container image is more than a packaged application. It is an executable representation of source code, operating-system components, libraries, configuration defaults, metadata, and the instructions required to assemble these elements. In a DevOps environment, the image becomes a critical interface between development, security, operations, and release management. A poorly designed image can increase build time, network consumption, attack surface, deployment risk, and recovery complexity. A well-engineered image, by contrast, is reproducible, small enough for efficient distribution, traceable to its source, and protected by appropriate supply-chain controls.

Image engineering therefore extends beyond writing a syntactically correct Dockerfile. It involves understanding the build context, controlling layers, exploiting cache behavior, separating build-time and runtime concerns, selecting trustworthy base images, and establishing reliable tagging and versioning practices. Secure build practice adds another dimension: vulnerabilities must be identified, image integrity must be verifiable, software contents must be documented, and the relationship between source, build process, and released artifact must be supported by evidence.

This chapter examines image construction as both a technical and governance activity. Docker and BuildKit are used as the principal examples, although the underlying ideas apply to OCI-compatible image builders and registries more broadly. The discussion also connects image engineering with Kubernetes operations, because the quality and trustworthiness of an image directly affect cluster security and operational reliability.

Learning Objectives

After studying this chapter, the reader should be able to:

1. Explain Docker build contexts, image layers, cache keys, and reproducibility.

2. Design efficient Dockerfiles using appropriate instruction ordering and multi-stage builds.

3. Apply BuildKit features such as parallel execution, secret mounts, cache mounts, and provenance generation.

4. Select image tags and versioning strategies that support traceability and safe deployment.

5. Evaluate images using vulnerability scanning, SBOM generation, signing, provenance, and admission controls.

6. Identify common image-security failures and recommend practical improvements.

7. Apply these techniques to an organizational image supply-chain workflow.

Images as Layered, Distributed Build Artifacts

A Dockerfile is a declarative build specification. Each instruction generally contributes a filesystem change or metadata change to the resulting image. Filesystem changes are represented as layers, while the final image configuration describes properties such as the entrypoint, environment variables, working directory, and exposed ports. Layers are content-addressed: their identities depend on their contents, which allows registries and hosts to reuse identical data.

Layering has two important consequences. First, layers support efficient distribution. If an application image changes only in its final application layer, unchanged base and dependency layers need not be transferred again. Second, layers influence security and confidentiality. Deleting a file in a later layer does not necessarily remove it from earlier layers. Consequently, a secret copied into an image during an earlier step may remain recoverable even if a subsequent instruction deletes it. Sensitive material must never be placed in ordinary image layers.

The build context is the set of files made available to the build process. When a command such as `docker build .` is executed, the directory represented by the dot is normally the context. The Dockerfile can copy only files within that context, subject to exclusions in `.dockerignore`. A large context slows builds and may unintentionally disclose source files, credentials, local caches, test data, or configuration. A carefully designed context is therefore both a performance measure and a security boundary.

A `.dockerignore` file should exclude items such as `.git`, local dependency directories, editor files, test reports, temporary output, credentials, and operating-system metadata. It should be reviewed as part of the repository rather than treated as a minor convenience. The context should contain what the build needs, not everything that happens to exist in the developer’s working directory.

Dockerfile Design: From Correctness to Efficiency

A reliable Dockerfile begins with an explicit base image and a clear separation between dependency installation, compilation, testing, and runtime execution. The order of instructions matters because Docker and BuildKit attempt to reuse previously produced results. A common pattern is to copy dependency descriptors before application source code:

```dockerfile

FROM node:22-bookworm-slim AS build

WORKDIR /src

COPY package.json package-lock.json ./

RUN npm ci

COPY . .

RUN npm test && npm run build

FROM node:22-bookworm-slim AS runtime

WORKDIR /app

ENV NODE_ENV=production

COPY --from=build /src/package.json /src/package-lock.json ./

RUN npm ci --omit=dev

COPY --from=build /src/dist ./dist

USER node

CMD ["node", "dist/server.js"]

```

If application source changes but dependency descriptors remain unchanged, the dependency-installation step can be reused. If all files are copied before dependency installation, even a minor source change can invalidate the expensive dependency layer.

This optimization must not be confused with blindly combining every command into one `RUN` instruction. Combining related commands can reduce unnecessary intermediate layers, but readability and cache behavior remain important. A package index should be updated and packages installed in the same instruction so that stale package metadata is not preserved independently:

```dockerfile

RUN apt-get update \

&& apt-get install -y --no-install-recommends ca-certificates \

&& rm -rf /var/lib/apt/lists/*

```

The use of `--no-install-recommends` limits incidental packages. Removing package lists reduces image size, although it does not compensate for choosing an unnecessarily large base image. Image minimization should be guided by operational requirements, not by a single numerical target. A very small image can be difficult to debug or may omit certificates, time-zone data, locale support, or diagnostic utilities required by the application.

The `COPY` instruction is generally preferable to `ADD` for ordinary file copying. `ADD` has additional behavior, including archive extraction and remote-source semantics in some contexts, which can obscure what enters the image. Explicit operations make review and security analysis easier.

A Dockerfile should specify an appropriate `WORKDIR`, use an exec-form `ENTRYPOINT` or `CMD` when signal handling matters, avoid unnecessary environment variables, and run as a non-root user. The choice between `ENTRYPOINT` and `CMD` should reflect whether the executable is fixed or whether operators are expected to supply a default command that can be overridden.

Multi-Stage Builds and Separation of Concerns

Multi-stage builds use multiple `FROM` statements and selectively copy artifacts from one stage to another. Their central value is not merely smaller images; it is the separation of build dependencies from runtime dependencies. Compilers, package managers, test frameworks, source code, and temporary files can remain in a build stage while the runtime stage receives only the executable and necessary support files.

For compiled applications, the runtime stage may use a minimal distribution or a distroless image. For interpreted applications, the build stage can install development dependencies and the runtime stage can install only production dependencies. This arrangement reduces attack surface and makes the intended runtime contents visible in the Dockerfile.

Multi-stage design introduces compatibility considerations. A binary compiled against a particular C library may not run in a runtime image using a different library implementation. Static linking, compatible distribution families, or an appropriate runtime base must be selected deliberately. Similarly, copying only a binary may omit certificates, shared libraries, migration files, or localization data. The runtime stage should be tested as the actual production artifact rather than inferred from the successful build stage.

Named stages, such as `AS build` and `AS runtime`, improve readability. They also enable targeted builds, for example building a testing stage in continuous integration while publishing only the runtime stage. A well-designed stage structure can represent the organization’s delivery pipeline: dependency preparation, compilation, testing, security checks, and release packaging.

BuildKit and Advanced Build Control

BuildKit is a modern build engine that improves execution efficiency and supports advanced build features. It can execute independent steps concurrently, transfer only required context data, and provide improved caching. Its capabilities are especially valuable in distributed CI systems where build time and network traffic affect developer productivity.

Cache behavior is based on instruction definitions, relevant files, build arguments, and prior results. Cache invalidation is not arbitrary; it reflects whether the builder can safely reuse a result. Developers should therefore place stable operations early and volatile operations later. Dependency lock files should be copied before source code, and generated outputs should not be included in contexts unless required.

BuildKit cache mounts allow package-manager caches to persist outside the final image:

```dockerfile

syntax=docker/dockerfile:1.7

FROM python:3.12-slim AS build

WORKDIR /src

COPY pyproject.toml uv.lock ./

RUN --mount=type=cache,target=/root/.cache/pip \

pip install --prefix=/install -r requirements.txt

COPY . .

```

The exact command depends on the project’s dependency tool, but the principle is consistent: reuse downloaded packages during builds without copying the cache into the final artifact. Cache mounts improve speed but should not be assumed to provide correctness. A build must remain functional when the cache is empty.

Secrets should be supplied through BuildKit secret mounts rather than `ARG` or `ENV`. Arguments and environment variables can become visible in image history, metadata, logs, or downstream diagnostics. A conceptual example is:

```dockerfile

RUN --mount=type=secret,id=private_token \

./download-private-dependency.sh

```

The build command supplies the secret through the builder’s secret mechanism. The secret is available only during the relevant instruction and is not intentionally committed to the resulting layer. Access should still be limited, audited, and scoped to the required repository or service.

BuildKit can also produce attestations, including provenance and SBOM-related metadata. Provenance describes how an artifact was built: the source reference, builder identity, parameters, and process information. Depending on configuration, provenance may be minimal or may expose additional build details. Organizations must balance auditability with the risk of disclosing sensitive repository or infrastructure information.

Tagging, Digests, and Versioning

A tag is a human-readable reference such as `orders-api:2.4.1` or `orders-api:release-2025-03`. Tags are mutable references: a registry administrator or automated process may move a tag to a different image. A digest, such as `sha256:...`, identifies immutable image content. Production deployment should therefore record or enforce digests, even when tags are used for human communication.

The `latest` tag is not a versioning strategy. It communicates neither compatibility nor release identity and can produce different results at different times. A stronger approach uses immutable semantic versions or organization-specific release identifiers and records the corresponding digest in deployment configuration. Tags such as `2`, `2.4`, and `2.4.1` can express compatibility expectations, but mutable floating tags should be used cautiously in production.

Versioning must cover more than application source. A new base-image digest, operating-system patch, dependency lock-file change, or build-tool update can alter the artifact even if the application version remains unchanged. Release records should therefore preserve the source revision, Dockerfile revision, base-image digest, dependency lock files, builder identity, scan results, SBOM, signatures, and final image digest.

Reproducibility means that the same declared inputs produce the same or functionally equivalent artifact. Absolute bit-for-bit reproducibility may be difficult because timestamps, package indexes, compiler behavior, and external repositories can vary. Pinning base images by digest, using lock files, controlling timestamps where possible, and avoiding unversioned downloads improve reproducibility. Reproducibility is not identical to security, but it strengthens the ability to investigate and verify a release.

Image Scanning and Vulnerability Interpretation

Image scanning analyzes operating-system packages, language dependencies, and sometimes configuration or secret patterns. A scanner maps discovered components to vulnerability databases and reports severity, affected versions, and remediation information. Scanning is useful, but its output requires interpretation.

A vulnerability in an image does not automatically imply exploitable risk. The vulnerable package may be unused, unreachable, disabled, or protected by application controls. Conversely, a scanner’s low or unknown rating does not guarantee safety. A critical issue in a reachable network service deserves immediate attention, while a high-severity issue in an unused command-line utility may require a different response. Organizations should combine severity with exploitability, exposure, asset criticality, reachability, available fixes, and compensating controls.

Scanning should occur at multiple points: during pull-request validation, during image build, when an image is pushed, and periodically after publication. The last stage is essential because newly disclosed vulnerabilities can affect images that were previously approved. Fail-the-build policies should be risk-based. Blocking every finding may make delivery unusable; ignoring all findings turns scanning into a reporting exercise. Exceptions should be documented, time-limited, owned by a responsible team, and reviewed.

Remediation generally begins with rebuilding from an updated base image or updating a direct dependency. Manual modification inside a running container is not an acceptable permanent fix because it is not represented in the Dockerfile or source-control process. If no patched version exists, teams should assess exposure, apply compensating controls, and track the issue explicitly.

SBOM, Signing, and Provenance

A software bill of materials (SBOM) is an inventory of components contained in an artifact. It may include package names, versions, relationships, licenses, and identifiers such as package URLs or vulnerability-database references. SBOMs support vulnerability response, license review, asset inventory, and incident analysis. They do not prove that an image is safe; they provide visibility into what must be evaluated.

SBOMs should be generated for the final image and ideally associated with the image digest as an attestation. Generating an SBOM only for the source repository can miss base-image packages and build-time transformations. Conversely, an SBOM containing only operating-system packages may omit application dependencies. The format and coverage should be defined by organizational policy.

Signing provides evidence that an image or related artifact was approved or produced by a recognized identity. Modern signing systems can use keyless identities tied to an identity provider and short-lived certificates, or they can use managed keys. Signature verification must be integrated into the deployment path; a signature that is never checked is merely archival information.

Provenance records the origin and construction of an artifact. It can support questions such as: Which source revision produced this image? Which workflow and builder were used? Were untrusted inputs introduced? Was the image built by an approved pipeline? Provenance is particularly valuable when a registry contains many similarly named tags or when an incident requires identifying all artifacts derived from a compromised dependency.

These controls address different questions:

• The digest asks, “Which exact artifact is this?”
• The signature asks, “Who authorized or produced it?”
• The SBOM asks, “What components does it contain?”
• Provenance asks, “How and from which inputs was it produced?”
• Scanning asks, “What known risks are associated with its contents or configuration?”

A mature supply-chain policy uses these controls together rather than treating any one of them as sufficient.

A Secure Image Supply-Chain Workflow

An organizational workflow can be modeled as a sequence of controlled transitions:

1. Source preparation: Review Dockerfiles, dependency lock files, build scripts, and `.dockerignore` rules.

2. Build isolation: Run builds in an approved, ephemeral or controlled builder with restricted network and secret access.

3. Test and quality checks: Execute unit, integration, and image-level tests, including validation that the runtime image starts as a non-root user where intended.

4. Artifact construction: Build with pinned inputs and generate the image digest, SBOM, and provenance.

5. Security evaluation: Scan the image and dependencies; apply policy thresholds and record exceptions.

6. Signing and publication: Sign the digest and publish it to a controlled registry with appropriate access policies.

7. Deployment admission: Require approved signatures, provenance, and vulnerability status before deployment to protected environments.

8. Continuous monitoring: Rescan published images, monitor base-image updates, and rebuild when dependencies or vulnerability intelligence changes.

In Kubernetes, admission controls can reject images that are not signed, are not from approved registries, or are referenced only through unsafe mutable tags. Deployment manifests should record immutable digests or use a controlled promotion mechanism that resolves a release tag once and preserves the resulting digest. Runtime security controls remain necessary because a trusted image can still contain application defects or be misused through insecure configuration.

Illustrative Case Study: Securing a Payment-Service Image Pipeline

Background

A fictional organization, Meridian Pay, operates a payment API across several Kubernetes clusters. Its initial pipeline builds images from a large language-runtime base, copies the entire repository into the image, installs dependencies without a lock file, and publishes both `latest` and environment-specific tags. The deployment platform pulls the tag specified in a Helm values file.

Situation and Problem

Builds are slow and inconsistent. A developer discovers that a local configuration file was included in a test image. A subsequent vulnerability review finds operating-system packages that are not needed at runtime. The security team also cannot determine which source revision produced an image running in production because tags have been overwritten.

Analysis

The problems have related causes. The build context is too broad, dependency resolution is not deterministic, and development tools are shipped into production. The release process treats a mutable tag as an identity. There is no reliable SBOM, signature, or provenance record, so incident response depends on informal information from the development team.

Approach and Solution

Meridian Pay first adds a reviewed `.dockerignore` file and separates dependency descriptors from application source in the Dockerfile. The build is converted to a multi-stage process: a build stage installs development dependencies, runs tests, and compiles assets; a runtime stage contains only production dependencies, application files, certificates, and a non-root user.

The CI system enables BuildKit cache mounts for dependencies and secret mounts for access to a private package repository. The base image is selected from an approved source and pinned by digest. A release pipeline assigns a semantic version and records the resulting digest rather than relying on `latest`.

The pipeline generates an SBOM and provenance attestation, scans the final image, and signs the digest using the organization’s approved identity. Kubernetes admission policy permits only images from the private registry that have a valid signature and acceptable scan status. The deployment record includes the source commit, image digest, SBOM location, and exception approvals.

Outcome

Build time decreases because dependency layers and package caches are reused. The runtime image contains substantially fewer components and no development toolchain. Production deployments become auditable: operators can identify the exact artifact, its source revision, its declared contents, and its approval status. When a vulnerability is disclosed, the organization can query SBOM records to identify affected releases and rebuild them systematically.

Learning Points

The case demonstrates that optimization and security frequently reinforce each other. Smaller runtime stages reduce transfer cost and attack surface; pinned inputs improve both reproducibility and incident analysis; and signed, attested artifacts make deployment policy enforceable. None of these controls removes the need for secure coding, runtime configuration, or human review, but together they transform image production from an informal packaging step into a controlled engineering process.

Risks, Limitations, and Common Mistakes

One common mistake is assuming that a small image is automatically secure. Image size is only a proxy for the number of components; a small image can still contain a vulnerable application library or unsafe configuration. Another mistake is using a trusted base-image name without verifying its publisher, update policy, digest, and provenance.

Secrets placed in `ARG`, `ENV`, copied files, shell history, or build logs can leak even when the final application does not use them. Developers also sometimes install packages without pinning versions, download scripts over insecure or unaudited channels, or execute remote content during a build. These practices reduce transparency and reproducibility.

Running as root increases the potential impact of application compromise, but changing the user alone does not solve all container risks. File ownership, writable directories, Linux capabilities, network access, and Kubernetes security settings must be considered together. Similarly, signing an image does not make its contents safe; it only provides origin or authorization evidence.

Caching has risks as well as benefits. A stale or improperly shared cache can create confusion, and caches should not be treated as trusted sources for secrets or unverified artifacts. CI builders require access controls, isolation, and monitoring. Remote builders and shared caches should be evaluated for tenant isolation and data exposure.

Scanner limitations include false positives, incomplete package detection, delayed vulnerability intelligence, and difficulty evaluating application reachability. SBOMs may also be incomplete if build tools or dynamic downloads are not captured. Governance must therefore define evidence quality, acceptable uncertainty, review responsibilities, and escalation procedures.

Governance, Ethics, and Professional Responsibility

Image security involves decisions about risk, transparency, and accountability. Organizations should define who owns base-image maintenance, who approves exceptions, how long exceptions remain valid, and which evidence is required before production release. Vulnerability remediation targets should reflect system criticality rather than being identical for every workload.

Licensing information in an SBOM can reveal obligations associated with open-source components. Legal and engineering teams should establish processes for attribution, license compatibility, and redistribution. Security teams should also avoid treating vulnerability scores as a substitute for professional judgment. Automated policy is valuable when it is explainable, consistently applied, and subject to controlled exception handling.

Supply-chain records may contain repository names, build parameters, or identity information. They should be protected against unauthorized disclosure while remaining available to auditors and incident responders. Ethical practice requires accurate reporting of scan results and known limitations; suppressing findings to meet release targets undermines the purpose of the control.

Emerging Directions

Image delivery is increasingly moving toward policy-driven and attested workflows. Build systems can generate provenance and SBOM attestations automatically, registries can store them alongside image manifests, and admission controllers can evaluate them before deployment. This supports a broader shift from “scan and publish” to continuous verification of artifact identity, origin, contents, and policy status.

The OCI ecosystem is expanding beyond traditional container images to include signatures, attestations, and related artifacts. Developers are also adopting reproducible-build techniques, hermetic or restricted-network builds, dependency policies, and automated base-image refresh services. Artificial intelligence may assist with Dockerfile analysis, dependency-risk prioritization, and remediation recommendations, but generated recommendations require review because they can misunderstand runtime behavior, licensing, or exploitability.

The strategic direction is clear: image construction is becoming an evidence-producing activity. A production artifact is expected not only to run, but also to explain what it contains, where it came from, how it was built, and why it was permitted to reach an environment.

Best Practices for Professional Use

Effective image engineering can be summarized through the following practices:

• Keep the build context minimal and maintain an explicit `.dockerignore`.
• Use trusted, maintained base images and pin production inputs by digest.
• Order Dockerfile instructions to preserve useful cache reuse.
• Use multi-stage builds to exclude compilers, tests, source, and development dependencies from runtime images.
• Supply credentials through ephemeral secret mounts, never ordinary build arguments or image environment variables.
• Run applications as non-root users and remove unnecessary packages, capabilities, and writable paths.
• Use lock files and controlled repositories to improve reproducibility.
• Treat tags as communication labels and digests as artifact identities.
• Generate SBOM and provenance data for the final artifact.
• Scan at build time and continuously after publication.
• Sign images and enforce signature and provenance verification at deployment.
• Make exceptions explicit, owned, time-limited, and reviewable.
• Test the final runtime image, not merely the build stage.

Chapter Summary

Image engineering combines Dockerfile design, build-context control, layer and cache management, multi-stage construction, and disciplined versioning. BuildKit improves performance and enables secure secret handling, cache mounts, and attestations. Efficient images should also be operationally complete: excessive minimization can remove required certificates or runtime libraries.

Secure image supply chains use complementary controls. Vulnerability scanning identifies known risks; an SBOM inventories components; a digest identifies exact content; signing establishes producer or approval identity; and provenance records the build origin and process. These controls become most effective when integrated into CI/CD and Kubernetes admission policies. The resulting approach supports reproducibility, rapid remediation, auditability, and informed risk decisions while recognizing that no individual control guarantees security.

Key Terms

Build context: The files and directories made available to a container image builder.

`.dockerignore`: A file specifying context content that should be excluded from a build.

Image layer: A content-addressed filesystem change or related image component produced during construction.

Build cache: Previously produced build results that can be reused when relevant inputs have not changed.

BuildKit: A modern Docker build engine supporting efficient execution, advanced mounts, caching, and attestations.

Multi-stage build: A Dockerfile design using multiple build stages to separate construction tools from runtime contents.

Base image: The starting image specified by a `FROM` instruction.

Runtime image: The image intended to execute the application in a target environment.

Digest: An immutable content-derived identifier for an image or manifest.

Tag: A human-readable, potentially mutable reference to an image.

Reproducible build: A build whose declared inputs produce the same or predictably equivalent artifact.

SBOM: A software bill of materials listing components and their relationships within an artifact.

Provenance: Evidence describing an artifact’s source, builder, parameters, and construction process.

Image signature: Cryptographic evidence connecting an artifact to a signing or approval identity.

Vulnerability scan: Automated analysis that identifies known security weaknesses in image contents or configuration.

Attestation: Signed or associated metadata providing claims about an artifact, such as its SBOM or provenance.

Build secret: Sensitive information made temporarily available to a build step without intentionally storing it in the image.

Admission control: A deployment-time policy mechanism that accepts or rejects workload specifications.

Software supply chain: The people, processes, tools, dependencies, and artifacts involved in producing and delivering software.

Review Questions

Short Answer Questions

1. What is the relationship between a Docker build context and a `.dockerignore` file?

2. Why are dependency descriptor files commonly copied before application source code?

3. Distinguish an image tag from an image digest.

4. What information does an SBOM provide?

5. Why should secrets not be supplied through Dockerfile `ARG` instructions?

Long Answer Questions

1. Explain how multi-stage builds improve both image efficiency and security. Include compatibility issues that may arise between build and runtime stages.

2. Describe BuildKit’s principal contributions to build performance and secure build execution.

3. Explain how vulnerability scanning, SBOMs, signatures, and provenance complement one another in a container supply chain.

4. Develop a versioning and release policy for images used in production Kubernetes clusters.

5. Discuss the limitations of image minimization and vulnerability scanning as security strategies.

Analytical / Application Questions

1. A team copies its entire repository into an image, installs dependencies after every source change, and publishes only a `latest` tag. Analyze the technical and governance problems and propose a redesign.

2. A scanner reports a high-severity vulnerability in an unused package within a production image, while a medium-severity issue affects a network-facing library. How should the release team prioritize its response?

3. Design a CI/CD and Kubernetes admission workflow that ensures only traceable, scanned, signed, and approved images are deployed.

22. Multiple Choice Questions with Answers

Question 1

Which Dockerfile change most directly improves cache reuse when application source changes frequently but dependencies do not?

A. Copy the entire repository before installing dependencies

B. Copy dependency descriptor files, install dependencies, and then copy source code

C. Disable the build cache for every build

D. Place the application source in the base image

Correct Answer: B. Copy dependency descriptor files, install dependencies, and then copy source code

Question 2

Why is a multi-stage build commonly used for a compiled application?

A. It guarantees that all vulnerabilities are removed

B. It allows build tools and source code to be excluded from the runtime image

C. It makes image tags immutable

D. It eliminates the need for runtime testing

Correct Answer: B. It allows build tools and source code to be excluded from the runtime image

Question 3

Which mechanism is most appropriate for using a private repository credential during a BuildKit build?

A. An ordinary Dockerfile ARG

B. An ENV instruction in the runtime stage

C. A BuildKit secret mount

D. A file copied into the final image

Correct Answer: C. A BuildKit secret mount

Question 4

Which statement best describes an image digest?

A. A mutable human-readable release label

B. An immutable content-derived identifier

C. A vulnerability severity score

D. A list of image dependencies

Correct Answer: B. An immutable content-derived identifier

Question 5

What is the principal purpose of an SBOM?

A. To identify the exact Kubernetes node running a container

B. To inventory software components contained in an artifact

C. To replace cryptographic image signing

D. To reduce the number of image layers automatically

Correct Answer: B. To inventory software components contained in an artifact

Question 6

A valid image signature primarily provides evidence about which question?

A. Who produced or approved the artifact

B. Whether every component is vulnerability-free

C. Whether the image will use little memory

D. Which Kubernetes namespace will run the image

Correct Answer: A. Who produced or approved the artifact

Question 7

Which practice most improves deployment traceability?

A. Using only the latest tag

B. Overwriting environment tags after every build

C. Recording the released image digest with its source revision

D. Deleting build metadata after publication

Correct Answer: C. Recording the released image digest with its source revision

Question 8

Why should a final runtime image be tested directly?

A. The build stage always has fewer dependencies

B. The runtime stage may omit libraries, certificates, or files needed by the application

C. Testing the runtime image invalidates all caches

D. Runtime images cannot contain application defects

Correct Answer: B. The runtime stage may omit libraries, certificates, or files needed by the application

Question 9

What does provenance metadata primarily describe?

A. The image’s network bandwidth consumption

B. The source and process used to construct the artifact

C. The number of Kubernetes replicas

D. The license text of every dependency only

Correct Answer: B. The source and process used to construct the artifact

Question 10

Which Kubernetes control can enforce that only approved signed images are deployed?

A. Admission control

B. A Dockerfile comment

C. A package-manager cache

D. A mutable image tag

Correct Answer: A. Admission control