A strong answer
An accepted Deployment update means the Kubernetes API server validated and stored the desired object. Controllers still need to reconcile it: the Deployment controller updates a ReplicaSet, the scheduler assigns Pods to nodes, and node agents ask the container runtime to start containers.
A Pod can remain pending because of resource constraints or placement rules, fail to start because an image cannot be pulled, or run without becoming ready because its readiness probe fails. Readiness determines whether the workload should receive traffic through the Service's endpoint mechanism. Liveness is about restarting an unhealthy container and should not be used as a substitute for readiness.
I would inspect Deployment and ReplicaSet status, Pod conditions, events, container state, probe results, and application metrics. The control plane accepting a change is not a transaction that guarantees user-visible readiness.
Follow-up direction
Describe how you would make a rollout pause safely and what signals should gate promotion.