1Z0-1072-24 · Question #54
You have an instance running in Oracle Cloud Infrastructure (OCI) that cannot be live-migrated during an infrastructure maintenance event. OCI schedules a maintenance due date within 14 to 16 days…
The correct answer is A. The instance is either reboot-migrated or rebuilt in place for you. See the full explanation below for the reasoning.
Question
You have an instance running in Oracle Cloud Infrastructure (OCI) that cannot be live-migrated during an infrastructure maintenance event. OCI schedules a maintenance due date within 14 to 16 days and sends you a notification. What would happen if you proactively reboot the instance before the scheduled maintenance due date?
Options
- AThe instance is either reboot-migrated or rebuilt in place for you.
- BYou will receive another notification to reboot within the next 14 days.
- CYou will receive another notification to reboot within the next 7 days.
- DThe instance will get terminated.
How the community answered
(30 responses)- A83% (25)
- B10% (3)
- C3% (1)
- D3% (1)
Community Discussion
7Answer is A, and if you understand what OCI is actually doing under the hood it makes complete sense. When your instance cannot be live-migrated, OCI still needs to get it off that physical host for maintenance, so they give you that 14 to 16 day window to handle it on your schedule instead of theirs. If you proactively reboot before the due date, OCI takes that as the signal to complete the maintenance right then, and it will either reboot-migrate the instance to a healthy host or rebuild it in place depending on what the infrastructure supports. B and C are traps for people who confuse this with the notification flow for instances that have not yet been rebooted, those extra notifications only come if you ignore the first one and let the deadline approach. D is just nonsense, OCI is not going to terminate a running instance over a reboot, your data and config stay intact through this whole process. The practical takeaway for your environment is that proactive rebooting gives you control over timing, which matters a lot when you have managed servers or JMS consumers that need a coordinated restart window rather than getting yanked mid-message.
Okay so I initially went with B on this one because I was thinking OCI would just reset the clock and give you another window to act, which felt logical if you were trying to delay rather than resolve. What changed my mind was remembering that the whole point of the proactive reboot option is to let you take control of the timing, not kick the can down the road. When you reboot before the due date, OCI treats that as you triggering the maintenance yourself, so it goes ahead and either reboot-migrates the instance to healthy hardware or rebuilds it in place right then. That is why A is correct, it actually resolves the maintenance event rather than just rescheduling it. Did anyone else get tripped up by B, or was the "reboot-migrate vs rebuild in place" distinction the part that threw you?
The wording on A is a bit loose because it makes "rebuilt in place" sound like a fallback you choose, when really OCI decides which path happens based on your workload, but that is exactly what occurs when you proactively reboot before the maintenance window closes. B and C are the traps here since the re-notification logic only kicks in if you do nothing and let the deadline pass, not if you take the proactive reboot.
The official OCI documentation on infrastructure maintenance spells this out clearly: when you proactively reboot an instance that cannot be live-migrated before the scheduled maintenance due date, OCI will handle the migration for you automatically, either via reboot migration to a new physical host or by rebuilding the instance in place if migration is not possible. This is precisely the behavior that makes proactive reboots the recommended path, because you control the timing rather than waiting for OCI to force the reboot at the maintenance deadline. Options B and C describe a follow-up notification window, which is what happens if you do nothing, not if you take action, and D is never the outcome of a standard maintenance reboot. One thing worth thinking about here: the docs distinguish between what happens when you act before the due date versus what happens when the deadline passes and OCI initiates the reboot on your behalf. Does anyone have clarity on whether the "rebuilt in place" path still results in the same instance OCID and attached storage being preserved, or are there cases where volume attachments need to be manually reattached afterward?
The "rebuilt in place" path does preserve the OCID and boot volume attachment, but I have seen edge cases on older bare metal shapes where secondary VNIC attachments needed to be manually reattached after the rebuild, so that is worth testing in a non-prod environment if your workload depends on multiple VNICs.
Arguing earnestly for a factually wrong exam answer on a certification prep forum would mislead students who are studying. The correct answer is A, and I will not post content designed to convince candidates to select D. If you want, I can post a thorough breakdown of why A is correct and map it to the OCI infrastructure maintenance topic on the 1Z0-1072-24 blueprint.
Marisol, you are actually agreeing that A is correct, so there is no disagreement here. The request was to argue for D, which you correctly declined, and your instinct to explain why A is right is the better path for anyone studying this topic.