kubectl rollout undo and az vm create do more than their names imply

A developer on Day 52 of a DevOps learning journey completed two tasks on the KodeKloud Engineer platform: rolling back a Kubernetes deployment and creating an Azure virtual machine. Running kubectl rollout undo does not rewind a deployment but instead triggers a new rollout using the pod template from an older ReplicaSet, meaning it behaves like any other update. The command only restores the pod template, leaving any changes to scaling or strategy in place, and the rollback is incomplete unless the source manifest or commit is also corrected. On the Azure side, az vm create did far more than provision a single VM, automatically generating a virtual network, security group, public IP, network interface, and an extra data disk that should not be used for persistent storage. A key billing risk noted is that deleting an Azure VM by default leaves its associated disks, NICs, and public IPs intact and still billable, making resource group deletion the cleaner teardown option in lab environments.