AI/ML in Platform Automation: CNPA practice questions

AI and machine learning touch platform engineering from two directions: the platform has to run AI and ML workloads well, and AI can help automate the platform and the work of the people using it. This competency covers both, and associate-level questions tend to stay conceptual.

Running AI workloads starts with accelerators. Kubernetes includes stable support for AMD and NVIDIA GPUs through device plugins: an administrator installs the vendor's GPU drivers and device plugin on the nodes, and the cluster then exposes a schedulable resource such as nvidia.com/gpu that containers request the same way they request CPU or memory, with the restriction that GPUs are specified in the limits section. Dynamic Resource Allocation (DRA), which the Kubernetes documentation now lists as stable, lets device drivers and cluster administrators define device classes that workloads claim; Kubernetes allocates matching devices and places Pods on nodes that can reach them. The CNCF Cloud Native AI white paper explains why this matters: accelerators are expensive and in short supply, training needs large data volumes and distributed processing, and model serving often needs only a fraction of a GPU, so sharing and right-sizing directly affect cost.

A platform turns those building blocks into golden paths for data scientists, much as it does for application developers. The CNCF Platforms White Paper lists provisioning complete environments for scenarios such as MLOps among the use cases of a maturing platform. The Cloud Native AI white paper names Kubeflow as an example of a cloud native tool supporting ML operations, KServe as a model serving framework that autoscales with demand, and integration of tools such as JupyterLab so practitioners switch less between interfaces. Quotas, scheduling, observability and cost reporting apply to AI jobs just as they do to services.

In the other direction, AI is entering platform operations. The same white paper mentions K8sGPT, a CNCF project that uses the language capabilities of large language models to help Kubernetes operators in their daily work, and demonstrations of controllers with a natural-language interface that translate user requests into Kubernetes API calls. DORA's platform engineering research adds an organizational finding: AI is an amplifier, and when platform quality is high the effect of AI adoption on organizational performance is strong and positive, whereas with a low-quality platform it is negligible, because faster coding is swallowed by bottlenecks in testing, security reviews and deployment. A good platform therefore makes sure AI-generated changes pass through the same automated tests, policies and delivery paths as any other change.

Misconceptions include assuming Kubernetes schedules GPUs without any vendor components, treating AI assistance as a reason to skip review or testing, and thinking MLOps needs a separate platform rather than additional capabilities on the existing one.

At associate level, expect questions on how GPUs are requested and scheduled, which ecosystem tools support MLOps, why platform quality decides whether AI tooling pays off, and how guardrails apply to automated changes.