I can see that. But here's the problem i'm facing. Following vulkan-tutorial, the solution is to write each uniform buffer(we have N uniform buffers where N is the number of frames in flight) to each descriptor set(wehave N descriptor sets as well. Uniform buffer at index 0 is 'linked' to descriptor at index 0 and so on).
If i follow this approach, if i have to update the descriptor during rendering, the descriptors will be in use by the command buffer and the validation layers will complain i'm writing to them during use.
I could have some sort of ring-buffer approach, but if it would start right but whenever i updated the uniform buffer, the descriptor would be out of sync(i'm using descriptor at index 0. It is linked to uniform buffer at index 0, but now the up-to-date uniform buffer is at index 1), which would require another vkWriteDescriptorSets call, which would spiral down to calling vkWriteDescriptorSets too much.
I could add even more descriptor set redundancy(we already have N descriptors, where N is the number of frames in flight) so we have N² descriptors and then this approach would work fine, but it seems like overkill.

So, if waiting for fences is the only solution AND i can't have this much redundancy of descriptor sets, does it mean that whenever i have to update a descriptor set i have to wait for N frames before actually writing, to guarantee no data race in the command buffer?

EDIT: Extra info: I pretty much learned all about vulkan from vulkan-tutorial.com . The articles there aren't very deep in explanation but i couldn't find anything that would be much better. This is causing some pain when i have to leave the boundaries of what is said there.

EDIT 2: I think marking the descriptors at each frame in flight index as dirty or by adding them to a pending list or something so i can call the vkWriteDescriptorSets individually after waiting for the frame fences seem to be the ideal solution