If you are preparing for a System Administrator, System Engineer, Windows Administrator, or Infrastructure Engineer interview, knowing Active Directory concepts is only the beginning.

Experienced candidates are often evaluated through real-world troubleshooting scenarios:

How do you isolate the problem?
What do you check first?
Which tools do you use?
How do you avoid making the situation worse?
How do you identify the root cause?
How do you verify that the issue has actually been resolved?

This guide focuses on advanced Windows Server and Active Directory troubleshooting scenarios rather than repeating basic definitions.

Part 1 – Advanced Domain Authentication Scenarios

1. A user can log in with a local account but cannot log in with a domain account. How would you troubleshoot it?

First, I would determine whether the problem is specific to the user or the workstation.

I would check:

Network connectivity.
DNS configuration.
Whether the computer can locate a Domain Controller.
Whether the user account is locked or disabled.
Whether the computer has a healthy secure channel.
Time synchronization.
Authentication-related Event Viewer logs.

Useful commands include:

ipconfig /all
nslookup
nltest /dsgetdc:domain.com
nltest /sc_verify:domain.com

I would avoid immediately removing and rejoining the computer to the domain because that can hide the actual cause.

2. A user can log in to one computer but not another. What does that tell you?

It suggests the account itself may be functioning correctly and the problem may be specific to the second workstation.

I would compare:

DNS configuration
Network connectivity
Time synchronization
Computer account
Secure channel
GPO processing
Local security configuration
Event logs

This is an example of using scope isolation before making changes.

3. Users suddenly receive “There are currently no logon servers available.” What would you investigate?

I would interpret this as a possible Domain Controller discovery or connectivity problem.

I would investigate:

DNS
Network connectivity
Domain Controller availability
AD Site configuration
Firewall
Routing
DC service health
SYSVOL/NETLOGON availability

I would test DC discovery:

nltest /dsgetdc:domain.com

I would also check whether the problem affects one workstation or an entire site.

4. Users can authenticate, but authentication takes several minutes. What could cause this?

Possible causes include:

Slow or incorrect DNS
Incorrect AD Site configuration
Unavailable Domain Controller
Network latency
GPO processing delays
Logon scripts
Mapped drives
Offline resources
User profile problems
Authentication-related service delays

I would first determine whether the delay occurs during:

Credential authentication
“Applying Group Policy”
User profile loading
Desktop initialization

That helps narrow the investigation.

5. A user says their password was changed successfully, but the old password still works on one computer. What would you investigate?

I would investigate whether the computer is communicating with the expected Domain Controller and whether cached credentials or another authentication mechanism is involved.

I would check:

DC connectivity
DNS
Authentication source
Cached domain logon behavior
Existing sessions
Credential Manager
Applications/services using stored credentials

I would not immediately conclude that AD failed to update the password.

Part 2 – Secure Channel and Computer Account Problems

6. Multiple computers suddenly report that the domain trust relationship has failed. What could be happening?

If many computers are affected simultaneously, I would look for an infrastructure-level cause rather than repairing each workstation individually.

I would investigate:

Domain Controller availability
AD replication
DNS
Recent restore operations
Virtual machine snapshots
Domain changes
Computer account problems
Time synchronization
Security infrastructure

The scope is important: one computer suggests a workstation problem; many computers suggest an infrastructure problem.

7. A virtual machine was restored from an old snapshot and now has domain authentication problems. What would you investigate?

I would determine:

How old the snapshot is.
Whether the machine was previously active.
Whether its computer account changed.
Whether the machine’s secure channel is healthy.
Whether there are duplicate/rollback-related issues.
Whether AD or virtualization best practices were followed.

I would avoid repeatedly restoring old snapshots of domain controllers because directory services have specific recovery requirements.

8. How would you repair a broken secure channel?

First verify the problem:

Test-ComputerSecureChannel -Verbose

If appropriate:

Test-ComputerSecureChannel -Repair -Verbose

Depending on the environment and cause, other recovery methods may include resetting the computer account or rejoining the machine to the domain.

The correct approach depends on the root cause.

Part 3 – Advanced DNS Troubleshooting

9. A workstation can resolve public websites but cannot resolve internal AD resources. What does this suggest?

It suggests that internet DNS resolution is working while internal DNS resolution may be incorrect.

I would check:

ipconfig /all
nslookup

I would verify that the workstation is using the organization’s internal DNS servers.

Then I would test:

Domain name resolution
Domain Controller records
SRV records
Internal host records
DNS forwarding
DNS zones

10. A domain-joined computer is using Google’s DNS server. What problems could this cause?

Public DNS servers do not normally contain the internal AD DNS records required for domain services.

Potential problems include:

Domain Controller discovery failures
Domain join problems
Kerberos problems
GPO problems
LDAP discovery failures
Authentication delays
Replication-related DNS problems

The client should normally use the organization’s internal DNS infrastructure.

11. `_ldap._tcp.dc._msdcs` records are missing. What could be affected?

These records are important for locating Domain Controllers and AD services.

Potential consequences include:

Domain Controller discovery problems
Authentication problems
Domain join failures
Replication problems
GPO issues

I would investigate DNS registration, DNS health, the AD DNS zones and Domain Controller services before manually creating records.

12. DNS resolution works by IP address but not by hostname. What is your approach?

I would separate the problem into:

Name resolution
      ↓
DNS server
      ↓
DNS zone
      ↓
Record
      ↓
Client DNS cache
      ↓
Network connectivity

Useful commands:

nslookup server01
ipconfig /flushdns

Then I would verify the actual DNS record on the internal DNS server.

Part 4 – Group Policy Incident Scenarios

13. A security GPO was accidentally linked to the wrong OU. What would you do?

This is a change-management incident.

I would:

Confirm the affected scope.
Identify exactly which objects received the policy.
Disable/unlink the incorrect GPO if appropriate.
Restore the intended configuration.
Force policy refresh where necessary.
Verify affected systems.
Review why the change occurred.

I would avoid making multiple unrelated changes while the incident is active.

14. A GPO works for users but not computers. What could explain this?

I would determine whether the policy contains:

User Configuration settings
Computer Configuration settings

Then check:

Computer OU
User OU
GPO links
Security filtering
WMI filtering
Processing status
Client-side events

This is why understanding where the user and computer objects are located is important.

15. A GPO works for some computers in the same OU but not others. How would you isolate the issue?

I would compare a working computer with a non-working computer.

I would collect:

gpresult /h report.html

from both systems.

Then compare:

Applied GPOs
Security filtering
WMI filtering
Computer membership
DNS
DC connectivity
OS/version differences
Event logs

This is much faster than randomly modifying the GPO.

16. A user says their mapped drive disappears after every reboot. What would you investigate?

I would check:

GPO drive mapping
Logon scripts
User group membership
Drive mapping conflicts
Network availability
DNS
Authentication
Existing drive letters
GPO processing

I would first establish whether the mapping is created through GPO, script, or another management tool.

17. Group Policy processing is taking several minutes. How would you investigate?

I would identify whether the delay is caused by:

DNS
DC discovery
Network latency
GPO count/complexity
Scripts
Drive mappings
WMI filters
Unavailable network resources
Client-side processing

gpresult and Group Policy event logs would be useful starting points.

Part 5 – Active Directory Replication Scenarios

18. Replication between two Domain Controllers fails, but both DCs are online. What would you check?

I would investigate:

repadmin /showrepl
repadmin /replsummary
dcdiag

Then check:

DNS
Network connectivity
RPC
Firewall
Time synchronization
AD Sites
Replication topology
Event Viewer

I would identify the specific replication error before attempting a repair.

19. Replication failures occur only between two specific sites. What does that suggest?

The site-specific nature points toward infrastructure or topology associated with those sites.

I would investigate:

Site links
Subnets
Routing
WAN connectivity
Firewall
DNS
Replication schedule
Domain Controllers at each site

20. One DC has not replicated for several days. What should you consider before forcing replication?

I would first determine the cause and how long replication has been unhealthy.

I would investigate:

Replication errors
DNS
Network
Time
Event logs
Database health
Whether the DC is still a valid replication partner

For a severely stale Domain Controller, recovery decisions require more care than simply running a force-replication command.

21. AD replication is healthy, but SYSVOL is not replicating correctly. What would you investigate?

I would treat directory replication and SYSVOL replication as related but distinct areas.

I would investigate:

DFS Replication
SYSVOL state
DFSR event logs
Domain Controller health
Network connectivity
SYSVOL/NETLOGON shares

I would not assume that healthy AD object replication automatically means SYSVOL is healthy.

Part 6 – FSMO and Domain Controller Failures

22. The Domain Controller holding all FSMO roles has failed. What would you do?

First determine whether the DC is temporarily unavailable or permanently lost.

If recovery is possible, I would normally prioritize restoring the original DC appropriately.

If it is permanently lost, I would assess the FSMO roles and determine whether role seizure is required.

I would also consider:

DNS
Global Catalog
Replication
Time hierarchy
Other services hosted on that DC

FSMO seizure should not be treated as the normal replacement for a recoverable server.

23. The PDC Emulator is unavailable. What could be affected?

Potential effects depend on the environment, but areas to investigate include:

Time synchronization
Password-change handling
Account lockout processing
Certain Group Policy-related operations
Authentication-related behavior

I would determine whether another healthy Domain Controller can provide the required services while the PDC role holder is recovered or replaced.

24. A Domain Controller has permanently failed. Should you immediately create a new server with the same name?

Not necessarily.

First determine:

Whether the old DC can be recovered
Whether it held FSMO roles
Whether it was a Global Catalog
Whether DNS was hosted there
Whether replication references remain
Whether metadata cleanup is required

Replacement should follow a controlled recovery process.

Part 7 – Active Directory Object Problems

25. A computer was deleted accidentally from Active Directory. What recovery options might exist?

Possible recovery options depend on the environment and available backups.

I would investigate:

Active Directory Recycle Bin
Available AD/System State backups
Whether the computer object can be recreated
Whether the workstation’s secure relationship can be restored

The best recovery method depends on the state of the workstation and domain.

26. A user account was accidentally deleted. What would you check first?

I would determine whether:

AD Recycle Bin is enabled
A backup exists
The deleted object’s attributes are recoverable
Group memberships and permissions need restoration

Restoring the account is not necessarily the end of the task. I would verify important attributes and access afterward.

27. A user cannot access a resource after being added to a security group. What could be happening?

Possible causes include:

Existing logon token
Group membership not reflected in the current session
Replication delay
Incorrect permission assignment
Nested group configuration
Resource ACL issue

I would verify group membership and then have the user establish a new authentication session if necessary.

Part 8 – Security and Privileged Access

28. A Domain Admin account is being used for daily workstation administration. What would you recommend?

From a security perspective, privileged accounts should not normally be used for routine activities.

A better design separates:

Standard user accounts
Administrative accounts
Privileged operations

Additional controls may include:

MFA where applicable
Privileged Access Workstations
Restricted administration
Auditing
Least privilege

29. How would you investigate suspicious Domain Administrator activity?

I would preserve evidence and investigate systematically.

I would examine:

Security logs
Authentication events
Logon types
Source computers
Account activity
Group membership changes
Recent administrative changes
Endpoint/security monitoring

I would coordinate with the organization’s security/incident-response process rather than making uncontrolled changes.

30. A user reports that someone added them to a privileged group. What would you check?

I would verify:

Current group membership.
When the membership changed.
Which account performed the change.
From which system.
Relevant security logs.
Whether the change was authorized.

I would follow the organization’s security incident process if the change was unauthorized.

Part 9 – Windows Server Performance

31. A production Windows Server shows 100% CPU utilization. What is your troubleshooting process?

I would identify the process responsible rather than immediately restarting the server.

I would use:

Task Manager
Resource Monitor
Performance Monitor
Event Viewer
PowerShell

Then determine whether the process is:

Application-related
Windows service
Backup
Antivirus
Scheduled task
Update
Unexpected/malicious activity

The next action depends on the identified cause.

32. A server has plenty of free RAM but applications are slow. What else would you investigate?

Memory availability alone doesn’t prove that the server is healthy.

I would investigate:

CPU
Disk latency
IOPS
Storage capacity
Network latency
Application performance
Database performance
Antivirus scanning
Virtualization host performance

For a virtual machine, I would also examine the underlying hypervisor/storage infrastructure.

33. A server’s C: drive suddenly reaches 100% capacity. What would you check?

I would identify what consumed the space.

Potential areas include:

Event logs
Temporary files
Windows Update files
Application logs
Crash dumps
User profiles
Backup files
Database/log files

I would avoid randomly deleting system files.

After identifying the cause, I would safely reclaim space and determine why the growth occurred.

Part 10 – Windows Services and Recovery

34. A critical Windows service repeatedly stops. What would you investigate?

I would check:

Service dependencies
Service account
Event Viewer
Application logs
Startup configuration
Resource availability
Required files
Network dependencies
Recent changes

I would also determine whether the service is crashing or being intentionally stopped.

35. A server boots successfully but an application doesn’t start. How would you troubleshoot it?

I would establish whether:

The application service started.
Dependencies started.
Required ports are available.
The service account works.
Required files exist.
DNS/network dependencies are available.
The application generated errors.

Then I would check application and System event logs.

Part 11 – Windows Updates and Patching

36. Windows Updates repeatedly fail on one server. What would you check?

I would investigate:

Windows Update logs
Event Viewer
Disk space
Update services
Network connectivity
Proxy configuration
Component Store health
Pending reboot
Previous failed updates

I would identify the specific error code before attempting repairs.

37. After installing a Windows update, an application stops working. What would you do?

I would first establish the correlation and collect evidence.

I would check:

Application logs
Windows event logs
Service status
Dependencies
Configuration changes
Installed updates
Vendor documentation

If rollback is necessary, I would follow change-management and recovery procedures rather than immediately removing updates.

Part 12 – Backup and Recovery Scenarios

38. A critical Windows server is accidentally deleted. What is your first priority?

The first priority is to determine:

What was lost?
How critical is the service?
What recovery points are available?
How recent is the latest backup?
Can the service be restored elsewhere?
What dependencies exist?

Then I would select the recovery method based on the RPO/RTO requirements.

39. Why should you regularly test backups?

A successful backup job does not automatically prove that data can be recovered.

Testing validates:

Backup integrity
Recovery procedure
Recovery time
Application consistency
Dependencies
Actual RPO/RTO

A backup strategy should therefore include restore testing.

40. What is the difference between RPO and RTO?

RPO – Recovery Point Objective

The maximum acceptable amount of data loss measured in time.

Example:

RPO = 1 hour

The organization should be able to recover to a point no more than approximately one hour before the incident, depending on the implementation.

RTO – Recovery Time Objective

The target time within which a service should be restored.

Example:

RTO = 4 hours

Part 13 – File Server Troubleshooting

41. Users can connect to a file server but cannot open one particular folder. What would you investigate?

I would investigate:

NTFS permissions
Share permissions
Group membership
Inheritance
Explicit Deny permissions
Resource location
Authentication
SMB connectivity

I would compare the affected user’s effective access with a working user.

42. A user says they had access yesterday but lost access today. What would you investigate?

I would look for changes rather than immediately modifying permissions.

Possible causes:

Group membership changed
GPO changed
NTFS ACL changed
Share permission changed
Resource moved
Account changed
Replication issue
Access-based configuration changed

I would check change records and compare the current configuration with the previous state where possible.

Part 14 – Remote Administration

43. You cannot RDP to a Windows Server, but the server responds to ping. What would you check?

Ping only confirms that ICMP traffic is working.

I would check:

RDP service
TCP 3389
Windows Firewall
Network firewall
RDP configuration
User permissions
NLA
Server resource exhaustion
Network path

Useful tests include:

Test-NetConnection server01 -Port 3389

44. RDP works for administrators but not for standard users. What could cause this?

I would investigate:

Remote Desktop Users group
Local security policy
GPO
User rights assignment
RDS configuration
Licensing if applicable
Session limits

I would compare the permissions of a working and non-working user.

Part 15 – Real-World Incident Management

45. A senior manager asks you to reboot a production Domain Controller immediately. What would you do?

I would first establish why the reboot is being requested.

I would check:

Current impact
Server health
FSMO roles
DNS
Global Catalog
Other Domain Controllers
Replication
Maintenance/change window

If a reboot is necessary, I would assess redundancy and impact first.

Being senior in infrastructure administration means not making a potentially disruptive change simply because someone requested it without understanding the consequences.

46. You discover that two Domain Controllers have different configuration values. What would you do?

I would determine whether the difference is expected or indicates replication inconsistency.

I would compare:

AD objects
DNS
GPO
SYSVOL
Replication status

Then use:

repadmin /replsummary
repadmin /showrepl

I would avoid manually editing one DC until I understand why the difference exists.

47. A server problem disappears after reboot. Is the incident resolved?

Not necessarily.

A reboot may only remove the symptom.

I would determine:

What caused the original problem?
What evidence remains?
Are event logs available?
Can the issue recur?
Was there a resource exhaustion problem?
Was there an application crash?
Did a service fail?

The objective should be root-cause analysis, not simply restoring service temporarily.

Part 16 – Senior Interview Questions

48. How do you approach an unfamiliar production problem?

A strong answer is:

“I first establish the scope and business impact. I determine whether the issue affects one user, one machine, one service, one site, or the entire environment. Then I collect evidence, check recent changes, isolate the affected layer, and use appropriate monitoring and diagnostic tools. I avoid making multiple changes simultaneously because that can make root-cause analysis more difficult. Once the cause is identified, I apply the least disruptive fix, verify the result, and document the incident.”

This demonstrates a structured troubleshooting methodology.

49. How do you avoid making a production incident worse?

I follow a controlled process:

Understand the impact.
Preserve evidence.
Check recent changes.
Confirm the proposed change.
Assess dependencies.
Take a backup/snapshot only when appropriate and safe.
Make one controlled change at a time.
Verify the result.
Have a rollback plan.
Document the outcome.

The exact procedure depends on the system and change.

50. What is the difference between fixing a problem and finding the root cause?

Fixing the problem restores service.

Finding the root cause determines why the problem occurred and how to prevent it from happening again.

For example:

Restarting a failed service may restore an application.

But root-cause analysis might reveal:

The service was repeatedly crashing because the server was running out of disk space due to uncontrolled application logging.

The second approach provides a long-term solution.

Practical Command Reference

Network and DNS

ipconfig /all
ipconfig /flushdns
nslookup
ping
tracert

Domain Controller Discovery

nltest /dsgetdc:domain.com
nltest /sc_verify:domain.com

Group Policy

gpupdate /force
gpresult /r
gpresult /h C:\Temp\gpresult.html

AD Health

dcdiag
repadmin /replsummary
repadmin /showrepl

FSMO

netdom query fsmo

PowerShell

Test-NetConnection server01 -Port 3389
Test-ComputerSecureChannel -Verbose
Get-Service
Get-ADUser
Get-ADComputer
Get-ADDomainController

10 Scenarios to Practice Without Looking at the Answers

Before an interview, practice explaining these aloud.

Scenario 1

One user cannot log in, but everyone else can.

Scenario 2

An entire branch office cannot authenticate.

Scenario 3

Users experience five-minute logon delays.

Scenario 4

A GPO applies to some computers but not others.

Scenario 5

Two Domain Controllers show replication errors.

Scenario 6

A computer suddenly reports a broken trust relationship.

Scenario 7

Internal hostnames cannot be resolved, but internet websites work.

Scenario 8

A Domain Controller holding FSMO roles fails permanently.

Scenario 9

RDP works for administrators but not standard users.

Scenario 10

A production server becomes slow immediately after a configuration change.

For each scenario, answer using:

Scope → Evidence → Isolation → Diagnosis → Fix → Verification → Prevention

Key Takeaways

For a senior Windows Server/Active Directory interview, the interviewer is not only testing whether you know commands.

They are testing whether you can:

Troubleshoot methodically.
Identify the scope of an incident.
Understand dependencies.
Distinguish symptoms from root causes.
Use appropriate diagnostic tools.
Protect production environments.
Make controlled changes.
Verify fixes.
Think about prevention.

The strongest answer is rarely:

“I will restart the server.”

A stronger answer is:

“I’ll first establish the scope and impact, review recent changes and collect evidence. Then I’ll isolate the affected layer using the appropriate Windows, DNS, AD and network diagnostic tools. Once I identify the root cause, I’ll apply the least disruptive corrective action, verify the service, and document the incident.”

That demonstrates the troubleshooting mindset expected from an experienced System Administrator.

Quick Revision Checklist

Before your interview, make sure you can confidently troubleshoot:

Next in the series: Windows Server & Active Directory – Day 2, focusing on DNS, DHCP, advanced Group Policy, Windows networking and infrastructure troubleshooting.