NCA-GENM - Software Development - Section 4.3

Deploy production-level conversational AI with Helm charts.

Use Helm charts to package and deploy a conversational AI stack - including inference services, message routing, and dependent microservices - onto a Kubernetes cluster. Configure values files to manage resource limits, replicas, and environment-specific settings without modifying chart templates.

HelmKubernetes

Practice question for this objective

Free sampleSoftware Developmenthard

A platform team ships a conversational AI inference service as a Helm chart. The chart's values.yaml sets resources.limits for the inference container to one GPU. For a load-test environment, an operator must temporarily bump that to two GPUs per pod and raise replicaCount, but the chart lives in a shared repository that must not be edited and the values.yaml is tracked in version control. Which install-time mechanism applies these changes correctly without forking the chart or modifying tracked files?

  • AEdit the rendered manifests produced by helm template and apply them with kubectl, bypassing the chart for this environment.
  • BPass an environment-specific overrides file with -f loadtest-values.yaml, or use repeated --set flags, on the helm install or helm upgrade command line. Correct
  • CSet the desired GPU and replica values as shell environment variables before running helm install so the templates read them from the process environment.
  • DRun kubectl scale and kubectl set resources against the live Deployment after the chart is installed.
External values files and --set flags override chart defaults at install time without editing tracked chart files. Helm builds a single merged values tree before rendering, layering -f files and --set flags on top of the chart's values.yaml; templates then read GPU and replica fields from that merged tree, so external overrides flow through while the chart stays unmodified and release-managed.

Why A is wrong: Applying hand-edited manifests directly does change the running resources, which is why it looks workable, but it detaches the deployment from Helm release tracking so subsequent helm upgrade or rollback operations no longer manage the workload.

Why B is correct: Helm merges command-line value sources over the chart's values.yaml at render time, so an external -f file or --set flags override the GPU and replica fields without touching tracked chart files and keeps the workload under release management.

Why C is wrong: Reading process environment variables looks plausible because Helm does expose some environment context, but chart templates resolve container resources and replica counts from the merged values tree, not from arbitrary shell variables, so the settings would be ignored.

Why D is wrong: Imperative kubectl edits do take effect immediately, which is tempting under time pressure, but the next helm upgrade reconciles the Deployment back to the chart's declared values and silently reverts the manual change.

See more NCA-GENM practice questions, answers explained.

More in this domain

Back to all Software Development objectives, or the NCA-GENM cert hub.

Examworthy is not affiliated with or endorsed by NVIDIA. Original, blueprint-aligned practice material only.