It's possible depending on the platform, but still requires capacity panning ahead of time.
In many hypervisor platforms, there is a concept of "memory ballooning". This will allow you to specify a "current" amount of RAM, but also a "maximum" amount of RAM. The maximum is a hard limit that is defined ahead of time, but the ballooning mechanism allows a guest OS that has not fully allocated its maximum memory map on the hypervisor to extend what is allocated to it on-demand. This is mostly useful in lab environments, and for statically deployed workloads that you expect large and infrequent allocation spikes from (but not all at once if over-provisioning).
The same can apply to CPU resources, specifying a "max" amount of cores or core percentage, and allocating those from a "soft" value all the way up to a maximum "hard" value.
It's a trick of virtualization that can be seen as a direct parallel to hotswap hardware systems. We're pretending that the VM has extra memory slots that aren't populated, or extra CPUs that aren't populated. But we still have to define the slot count firmly.
You can typically add disk storage on the fly to nearly any kind of instance on most platforms without any of these worries.
However, cloud orchestration systems have generally well-implemented and automated deployment systems, making these kind of models much more useless (with the exception of adding storage, that's still almost always just as useful).
Consider than many providers charge per-capacity allocated, rather than capacity used. Implementing a dynamically vertically scaling instance model creates yet another layer of scheduling and resource allocation problems for providers - one is that any number of customers might want quite a few resources at the same time, but also that any one of those customers might make those instances bloat at any time.
The only way to properly plan from a cloud infrastructure perspective in that case would be to allocate instances by their maximum capacity, and rightfully charge for that allocation they could otherwise afford to another customer.
At that point, why not just use the maximum if you already have to pay for it? And if we're doing things by maximum capacity, then redefining instances becomes necessary again to accomplish vertical scaling.