Understand API Depreciations CKAD Practice Questions (Page 1)

Questions 1–5

1. 1application · medium

   A developer is creating a new `CronJob` manifest for a cluster running Kubernetes v1.24. The developer wants to use the latest stable API version. Which `apiVersion` should be used?

   • A`batch/v1`
   • B`extensions/v1beta1`
   • C`batch/v2alpha1`
   • D`batch/v1beta1`
   Reveal Solution Discussion Select an answer first
2. 2foundation · easy

   A developer wants to see all API versions served by the cluster, including deprecated ones. Which command should they use?

   • Akubectl explain --api-versions
   • Bkubectl version --api-versions
   • Ckubectl get apis
   • Dkubectl api-versions
   Reveal Solution Discussion Select an answer first
4. 3application · medium

   A team is migrating their `Deployment` manifests from `apps/v1beta2` to `apps/v1`. After updating the `apiVersion`, they notice that the `spec.selector` field is now required. What is the correct action?

   • ASet `spec.selector` to `{}` to use the default selector.
   • BRemove the `spec.selector` field because it is deprecated.
   • CKeep the manifest as-is; the API server will auto-generate the selector.
   • DAdd a `spec.selector` field that matches the labels in `spec.template.metadata.labels`.
   Reveal Solution Discussion Select an answer first
5. 4expert · hard

   A company runs a production cluster on Kubernetes v1.20. They have a critical application that uses `Deployment` with `apiVersion: apps/v1beta1`. The team is planning to upgrade to v1.21 next month, but they are concerned about downtime. The application is deployed via a CI/CD pipeline that reads manifests from a Git repository. What is the safest migration strategy?

   • AUse `kubectl convert` on the production manifests just before the upgrade.
   • BKeep the `apps/v1beta1` manifests and rely on the API server to serve them during the upgrade.
   • CUpgrade the cluster first, then update the manifests to `apps/v1`.
   • DUpdate the Git manifests to `apps/v1`, test in a staging cluster, then apply to production before the upgrade.
   Reveal Solution Discussion Select an answer first
6. 5application · medium

   A developer needs to update a CronJob manifest from `batch/v1beta1` to the current stable version. The cluster runs Kubernetes v1.25. After changing the `apiVersion` to `batch/v1`, the developer notices that the field `schedule` is now required and `jobTemplate` has a different structure. What is the most efficient way to ensure the manifest is valid before applying it?

   • AApply the manifest and rely on the API server to auto-convert the fields.
   • BRevert to `batch/v1beta1` and use a conversion webhook.
   • CRun `kubectl explain cronjob` to review the v1 schema and adjust the manifest fields accordingly.
   • DUse `kubectl create cronjob --dry-run=client -o yaml` to generate a valid manifest from scratch.
   Reveal Solution Discussion Select an answer first