CKAD Application Deployment Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  'kubectl create' will update a resource if it already exists

  Why it's wrong here

  'kubectl create' is an imperative command that issues a POST request to the Kubernetes API server, which expects the resource to be new. If a resource with the same name and namespace already exists, the API server returns a 409 Conflict error, and kubectl aborts with a message indicating the resource already exists. Unlike apply, create does not perform a three-way merge or update the existing object's spec; it is strictly for initial creation. To modify an existing resource, you must use kubectl apply, kubectl edit, kubectl replace, or kubectl patch, because create is not idempotent and will consistently fail on duplicates.

• ✓

  'kubectl apply' can create or update resources; 'kubectl create' only creates and fails if resource exists

  Why this is correct

  kubectl apply operates declaratively: it sends the object configuration to the API server, which computes a difference between the desired state, the current live object, and the last-applied configuration, then issues a PATCH (or a POST if the resource does not exist). This allows apply to transparently create new resources and update existing ones in the same workflow. In contrast, kubectl create is imperative and always attempts to create a fresh resource per invocation; if the API server finds an existing object with the same identity, it returns an error instead of reconciling the object. Therefore, apply is suitable for both initial creation and ongoing updates, while create is intentionally limited to one-time creation where failure on duplicates is desirable.

• ✗

  'kubectl apply' and 'kubectl create' are interchangeable

  Why it's wrong here

  These commands are not interchangeable because they implement different paradigms for resource management. kubectl create performs an imperative operation: it requires the resource to be absent, issues a POST, and does not record any managed fields or last-applied state for future merges. kubectl apply performs a declarative operation: it checks for existence, issues a POST or PATCH accordingly, and stores the submitted configuration in the last-applied-configuration annotation to enable smart three-way merging on subsequent applies. Additionally, create does not support removal of fields that were deleted from the configuration, nor does it gracefully handle conflicts with controller-managed fields, so using create when apply is expected will lead to errors or incomplete updates.

• ✗

  'kubectl apply' can only create resources, not update them

  Why it's wrong here

  kubectl apply is explicitly designed for both creation and mutation of Kubernetes resources, and it is the recommended command for declarative configuration management. When a resource already exists, apply uses the last-applied-configuration annotation to compute a three-way patch that adds, modifies, or removes fields to match the desired state, while preserving fields set by other controllers that are not in the local configuration (e.g., clusterIP, nodePort, or status). If apply could only create resources, it would be useless for continuous delivery pipelines, as re-runs of a manifest would fail. In practice, apply's update capability is what makes it idempotent and safe for repeated execution, unlike create which errors on existing resources.

Go deeper

Related to this question