Sure, it's definitely possible and common for ad-hoc troubleshooting. One of the examples in the official Kubernetes documentation illustrates how to run a command in a deployment with `kubectl exec`: https://kubernetes.io/docs/reference/kubectl/generated/kubectl_exec/
As stated in the documentation, when targeting a controller such as a deployment instead of an individual pod for `kubectl exec`, Kubernetes selects the first pod managed by the controller. So what it actually does is run the command within the first (or selected) container of the first pod managed by the controller, i.e. essentially the same as listing the pods of the deployment and running `kubectl exec` with the name of the first pod.
Is it best practice? It depends. Running a container shell within a pod or workload is often a quick and dirty way to identify the root cause of an application or component failure. Sometimes it might be required to resolve issues immediately within stateful workloads or components before the situation deteriorates and the fastest way is to spin up a container shell and run ad-hoc commands to fix or workaround the issue.
On the other hand, running ad-hoc commands in a container shell is not reproducible, automatable and difficult to audit. So in that sense it's far from best practice. Also some organizational contexts may advise against or outright forbid exec'ing into a container shell for security or compliance reasons, either through administrative or technical means.
