Cascade Regional Airlines' VNet is 10.30.0.0/16. The team has already created 10.30.0.0/24 for the public booking tier and 10.30.1.0/24 for crew-scheduling. Which of the following ranges can be safely used for a new airport-kiosk subnet without overlapping either existing subnet?
Select an answer to reveal the explanation.
Short Explanation
Booking already owns 10.30.0.0 through .0.255, and crew-scheduling owns 10.30.1.0 through .1.255. Anything landing inside either of those ranges is a collision — the first fully clean block after both is 10.30.2.0/24.
Full Explanation
10.30.0.0/24 spans addresses 10.30.0.0 through 10.30.0.255, and 10.30.1.0/24 spans 10.30.1.0 through 10.30.1.255; any new subnet must avoid every address in both ranges. 10.30.2.0/24 spans 10.30.2.0 through 10.30.2.255, which starts immediately after the crew-scheduling block ends and shares no addresses with either existing subnet, making it a safe choice. 10.30.1.128/25 spans 10.30.1.128 through 10.30.1.255, which is entirely contained within the already-allocated crew-scheduling /24, so it would collide directly with VMs already deployed there. 10.30.0.128/25 spans 10.30.0.128 through 10.30.0.255, entirely inside the booking-tier /24, creating the same kind of collision on that subnet instead. 10.30.0.0/23 spans 10.30.0.0 through 10.30.1.255 — a /23 covers two /24 blocks — so it swallows the booking tier and crew-scheduling subnets whole, and a subnet cannot be carved out of a range that already contains other subnets. Watch the alignment as well: a /23's network address must have an even third octet, so a range written as 10.30.1.0/23 is not a valid block at all rather than a slightly-shifted one. Before deploying the kiosk subnet, Cascade's team should double-check the VNet's subnet list in the portal to confirm 10.30.2.0/24 is not already reserved for another planned purpose.