AZ-104 Deploy and Manage Azure Compute Practice Question
After applying a custom image, a Linux VM stops at a black screen before the sign-in prompt. The administrator cannot use RDP or SSH and needs the fastest way to inspect the boot process. Which two actions should they take? Select two.
⚠ Common exam trap
It's easy for candidates to assume RDP/SSH are the only ways to diagnose a VM, overlooking that Boot diagnostics provides out-of-band access to boot-time information even when the OS is unresponsive.
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
✓
Enable Boot diagnostics on the virtual machine.
Enabling Boot diagnostics on the virtual machine allows the administrator to capture serial console output and screenshots of the VM during boot. This is the fastest way to inspect the boot process without requiring network connectivity (RDP/SSH), as the serial log provides kernel-level messages and the screenshot shows the display state at the point of failure.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Enable Boot diagnostics on the virtual machine.
Why this is correct
Enabling boot diagnostics on the VM is the necessary first step because it instructs Azure to capture both a screenshot of the guest display and the serial console log during the boot process. This setting can be enabled on an existing VM without downtime, and it must be active before a reboot so that the failing boot sequence is recorded. Without this, you have no insight into the black screen and are forced to guess at the cause.
- ✓
Review the screenshot and serial log in Boot diagnostics.
Why this is correct
Reviewing the screenshot and serial log is the direct diagnostic action that uses the captured data to locate the failure point. The serial log contains kernel and bootloader messages, while the screenshot shows the last rendered frame, allowing you to determine whether the boot stalled before the kernel, during driver loading, or at userspace handoff. This is a non-destructive, read-only step that provides evidence to guide a targeted fix.
- ✗
Reimage the VM immediately to a clean managed disk.
Why it's wrong here
Reimaging to a clean managed disk recreates the OS disk from a new managed image, which permanently wipes the custom image and any boot diagnostic evidence stored on the ephemeral OS disk. This action destroys the ability to analyze the root cause and may reintroduce the same problem if the custom image itself is flawed, such as due to an improper sysprep or missing virtio drivers. It also incurs downtime and costs without informing whether the failure would recur, making it an aggressive recovery step, not a diagnostic one.
- ✗
Increase the VM size to a larger SKU.
Why it's wrong here
Increasing the VM size to a larger SKU only changes the reserved vCPU/RAM and possibly disk bandwidth; a black screen during early boot is almost always caused by a guest OS-level issue like a broken kernel module or corrupted initramfs, not resource starvation. Moreover, a resize operation on a VM that's already failing could require a reboot that may further destabilize the boot process, and it still leaves you without any diagnostic data to confirm the hypothesis. Thus, this action is a speculative change that does not address the observed symptom.
When this WOULD be correct
If a VM is experiencing performance-related boot delays due to insufficient resources (e.g., high CPU/memory pressure) and the OS is otherwise healthy, increasing the SKU can resolve timeouts and allow the boot to complete.
- ✗
Reset the network interface configuration from the portal.
Why it's wrong here
Resetting the NIC configuration from the portal triggers a network interface reset at the Azure platform level, which affects IP address assignment and connectivity but has no bearing on the guest OS boot process that renders the screen. A black screen prior to login typically indicates a kernel panic, driver incompatibility, or bootloader misconfiguration, none of which would be influenced by NIC re-provisioning. Additionally, if the VM can't boot, you can't even access the portal to reset the NIC in a way that would help; the action is irrelevant to the symptom.
When this WOULD be correct
If a VM loses network connectivity after a configuration change and the administrator needs to restore access without redeploying, resetting the network interface from the portal can reinitialize the NIC and restore connectivity.
Option-by-option analysis
Why each answer is right or wrong
Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The AZ-104 exam frequently reuses these exact scenarios with slightly different constraints.
✓Enable Boot diagnostics on the virtual machine.Correct answer▾
Why this is correct
Enabling boot diagnostics on the VM is the necessary first step because it instructs Azure to capture both a screenshot of the guest display and the serial console log during the boot process. This setting can be enabled on an existing VM without downtime, and it must be active before a reboot so that the failing boot sequence is recorded. Without this, you have no insight into the black screen and are forced to guess at the cause.
✗Increase the VM size to a larger SKU.Wrong answer — click to see why▾
Why this is wrong here
Increasing the VM size does not address boot failures caused by a custom image issue; it only provides more resources, which won't fix a corrupted boot process or driver incompatibility.
★ When this WOULD be the correct answer
If a VM is experiencing performance-related boot delays due to insufficient resources (e.g., high CPU/memory pressure) and the OS is otherwise healthy, increasing the SKU can resolve timeouts and allow the boot to complete.
Why candidates choose this
Candidates may think that a larger VM provides more memory or CPU to handle a problematic boot, but this does not fix the underlying cause of a black screen (e.g., missing drivers or bootloader errors).
✗Reset the network interface configuration from the portal.Wrong answer — click to see why▾
Why this is wrong here
Resetting the network interface configuration does not address a boot failure at the black screen, which is a boot process issue unrelated to networking.
★ When this WOULD be the correct answer
If a VM loses network connectivity after a configuration change and the administrator needs to restore access without redeploying, resetting the network interface from the portal can reinitialize the NIC and restore connectivity.
Why candidates choose this
Candidates may confuse network connectivity issues with boot problems, assuming that a black screen is caused by a network misconfiguration preventing remote access.
Analysis generated from the official AZ-104blueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”
Go deeper
Related to this question
About these practice questions
This AZ-104 question is part of Courseiva's 1,049-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This AZ-104 practice question is part of Courseiva's free Microsoft 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 AZ-104 exam.