UCS Server Boots from Local Disk Instead of SAN After Reboot — Why?
Exhibit
<pre>
! Service profile boot policy configuration
boot-order:
boot-device:
- name: 'local-disk'
device-type: 'local-disk'
- name: 'san-target'
device-type: 'san'
wwnn: '20:00:00:25:b5:00:00:01'
wwpn: '20:00:00:25:b5:00:00:02'
lun: '0'
reboot-on-update: 'true'
</pre>Refer to the exhibit. A UCS administrator applies a service profile with this boot policy to a blade. The blade boots from the SAN LUN successfully. However, after a reboot due to a firmware update, the blade boots from the local disk instead of the SAN. What is the most likely reason?
Quick Answer
The answer is that the boot policy lists the local disk before the SAN target. This is the most likely reason because UCS Manager re-evaluates the boot order upon reboot, and if the local disk is present and has a higher priority in the policy, the blade will boot from it instead of the SAN LUN. The initial successful boot from SAN occurred because the local disk was not present at that time, but after a firmware update reboot, the local disk became available and took precedence due to its higher position in the UCS boot order. On the Cisco DCCOR / CCNP Data Center Core 350-601 exam, this scenario tests your understanding of how UCS boot policies are applied and re-evaluated after hardware changes or reboots, often trapping candidates who assume a successful boot means the order is correct. A common memory tip: "First in policy, first to boot — if local is listed first, SAN is just a backup."
⚠ Common exam trap
Candidates often assume a firmware update changes SAN parameters (like WWPN or LUN ID), but Cisco tests the concept that the boot order policy itself, not the SAN configuration, determines which device boots first when multiple bootable devices are present.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
The boot order has local disk before the SAN target.
The most likely reason is that the boot order in the service profile's boot policy lists the local disk before the SAN target. After a firmware update, the UCS Manager re-evaluates the boot policy, and if the local disk is present and has a higher priority, the blade will boot from it instead of the SAN LUN. The initial successful boot from SAN occurred because the local disk was not present at that time, but after the reboot, the local disk became available and took precedence.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The WWPN of the SAN target is incorrect.
Why it's wrong here
It worked before.
- ✗
The SAN target LUN ID changed after the firmware update.
Why it's wrong here
LUN ID is static.
- ✓
The boot order has local disk before the SAN target.
Why this is correct
Exhibit shows local-disk listed first.
- ✗
The local disk was not present at initial association.
Why it's wrong here
Possible but less likely; after reboot, local disk may have been inserted.
Go deeper
Related to this question
About these practice questions
Courseiva writes every 350-601 question from scratch — 984 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
1 more way this is tested on 350-601
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. A UCS administrator needs to ensure that server boot order always starts from the local disk if available, and falls back to a SAN LUN if local disk fails. Which boot policy setting should be used?
easy- A.Local Disk alone
- B.SAN first, then Local Disk
- C.SAN Boot Only
- ✓ D.Local Disk first, then SAN
Why D: The UCS boot policy allows you to specify a boot order where the local disk is attempted first. If the local disk is unavailable or fails, the system automatically falls back to the next boot device in the list, which is the SAN LUN. This ensures high availability and aligns with the requirement to prefer local boot while providing a failover path.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This 350-601 practice question is part of Courseiva's free Cisco certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the 350-601 exam.