Kustomize builds are defined in a kustomization.yaml in your directory. This file declares which files to process by listing them under the resources section, along with any patches and other customization steps. The actual manifest files (such as deployment.yaml or secrets.yaml) live alongside, but kustomize uses the list in kustomization.yaml to know which files to build and transform. Fields like metadata or apiVersion belong to the manifests themselves and aren’t where you specify the set of files to include. So the place to define the files to be built for a customization is the kustomization.yaml.

The key idea is dynamic storage provisioning. A Pod doesn’t talk to a StorageClass directly; instead, a PersistentVolumeClaim asks for storage and can specify a StorageClass by name. When the PVC is created with that StorageClass, the cluster’s provisioner creates a matching PersistentVolume to satisfy the claim, and the Pod can then mount it via the PVC. The StorageClass defines how to provision storage: which provisioner to use (the driver that actually creates the volume) and the provisioning parameters (such as storage type, performance characteristics, and other driver-specific options). It can also set handling details like reclaimPolicy and volumeBindingMode. Access modes are properties of the PVC and the resulting PV, not of the StorageClass itself. So, the resource that references a StorageClass to provision storage for a pod is the PersistentVolumeClaim, and the StorageClass describes the provisioning parameters and the storage type.

NetworkPolicy is about controlling how pods talk to each other by defining allowed ingress and egress rules. In OpenShift, the enforcement of these rules depends on the cluster’s network plugin (the CNI) supporting NetworkPolicy. If no policy selects a pod, that pod can communicate freely with others. When a policy does select certain pods, traffic to and from those pods is restricted to what the policy permits, effectively isolating them unless explicit allowances exist. This is how you implement precise control over pod communication and segment traffic. The other statements don’t describe traffic control at all: quotas for storage, automatic creation of service accounts, and encryption management for Secrets are unrelated to how NetworkPolicy governs pod traffic.

In OpenShift, an ImageStream is a resource that tracks container images within a project and provides a stable reference to a specific image tag in the cluster. Its purpose is to surface updates to images in a decoupled way so deployments can react automatically when a new image is available. When you push a new image and update the ImageStreamTag, OpenShift can trigger a new deployment for your application if an image change trigger is configured, allowing seamless automated rollouts without hard-coding image details in pod specs. This makes workflows like continuous delivery easier, as deployments can be driven by image updates to the ImageStream rather than manual edits. It’s not used for storing logs, defining network policies, or managing Secrets; those are handled by other resources and components in OpenShift.