Unix Interview Questions & Answers

— ny_wk

sudo vs su is one of the most common Linux interview questions, and the short answer is this: su switches you into another user's account (usually root) for a whole session, while sudo runs a single command with elevated privileges using your own password and a centrally audited policy. Master that distinction plus the sudoers syntax and you can answer most privilege-escalation questions a sysadmin interviewer will throw at you.

The questions below are grouped into topic sections the way a real interview flows: core concepts first, then the sudoers configuration, then practical scenarios and security. Each answer is corrected and accurate, so you can learn the material rather than memorize a quiz dump.

Core concepts: sudo vs su explained

Linux enforces security through strict user and permission boundaries. Ordinary users cannot perform system-wide changes such as installing packages, editing /etc, or restarting services. To cross that boundary you use su or sudo — and knowing exactly how each escalates privilege is the foundation of the sudo vs su comparison.

Q1. What is the difference between sudo and su?

su (substitute user) starts a new shell as a target user. With no username it targets root, so su or su - turns your terminal into a root session that persists until you type exit. It prompts for the target account's password — meaning users must know the root password.

sudo (superuser do) executes one command with elevated privileges and then returns you to your normal shell. It prompts for your own password (not root's) and only works if the sudoers policy authorizes you. This is why sudo is considered safer: the root password is never shared, every action is logged, and access can be scoped per user and per command.

Q2. What does the - in su - actually do?

su - (equivalently su -l or su --login) starts a login shell: it loads the target user's environment, runs their profile scripts, and changes the working directory to their home. Plain su keeps your current environment and PATH, which is a frequent source of "command not found" bugs when running admin tools. As a rule, prefer su - so you get root's full environment.

Q3. How do you run a root shell with sudo?

Use sudo -i for a root login shell (the modern replacement for su -) or sudo -s for a non-login root shell. sudo su - also works but is redundant. The advantage of sudo -i is that it still uses your password and your sudo authorization, so the root password can stay locked.

Q4. Is sudo a SUID binary, and why does that matter?

Yes. /usr/bin/sudo is owned by root and carries the setuid bit, which is why ls -l $(which sudo) shows an s in the owner-execute position (-rwsr-xr-x). The setuid bit lets the program run with the file owner's privileges (root) rather than the caller's, which is exactly how an unprivileged user can have sudo perform a privileged action on their behalf. Because of this, sudo must validate the caller against the policy before doing anything.

The sudoers file: how sudo vs su differ in configuration

The biggest practical difference in the sudo vs su debate is configuration. su has almost nothing to configure — it just asks for the target password. sudo is driven by a precise, auditable policy file, and interviewers love to test whether you can read and write it correctly.

Q5. Where is the sudo policy stored and how do you edit it safely?

The policy lives in /etc/sudoers, with drop-in fragments in /etc/sudoers.d/. Never edit it with a normal text editor. Always use:

1. sudo visudo — opens /etc/sudoers and syntax-checks it before saving, so a typo cannot lock everyone out of root.
2. sudo visudo -f /etc/sudoers.d/myrule — safely edits a drop-in file (the preferred place for custom rules).
3. sudo visudo -c — validates the current configuration without editing.

Note: a stale claim you may see online is that visudo lives at /usr/sbin/visudo and must be called by full path. On modern distributions visudo is on root's PATH, so sudo visudo is all you need.

Q6. What is the syntax of a sudoers rule?

A user specification has four parts:

user host = (run_as_user:run_as_group) command(s)

The default root entry reads root ALL=(ALL:ALL) ALL, meaning root may run any command as any user/group on any host.

Q7. How do you grant a user full sudo access?

Add the user to the admin group instead of editing rules by hand. On Debian and Ubuntu the group is sudo; on RHEL, CentOS, Rocky, and Fedora it is wheel.

1. Debian/Ubuntu: sudo usermod -aG sudo bob (the source's adduser bob sudo also works on Debian-family systems).
2. RHEL/Fedora: sudo usermod -aG wheel bob.
3. Have the user log out and back in so the new group membership takes effect.

The group itself is authorized in sudoers by a line like %sudo ALL=(ALL:ALL) ALL (Debian) or %wheel ALL=(ALL) ALL (RHEL). Granting everyone ALL=(ALL) ALL by listing many individual users is dangerous — it is effectively handing out root, so do it only for people you fully trust.

Scenario questions: writing real sudoers rules

Interviewers often present a permission scenario and ask you to write the exact line. These reinforce the sudo vs su theme because they show how finely sudo can scope access — something su simply cannot do.

Q8. Grant a DBA full access on one host only

User mark administers the database server beta.dbserver.com and should have full rights only on that host:

mark beta.dbserver.com=(ALL:ALL) ALL

On any other machine this rule does not apply, so mark gets no privileges there.

Q9. Let a user run commands as a specific non-root account

User tom should run commands as user oracle (not root) on the same server — common for service maintenance:

tom beta.dbserver.com=(oracle) ALL

He then runs, for example, sudo -u oracle sqlplus. This is a clean example of why sudo beats su: you delegate just the oracle identity without sharing the oracle password.

Q10. Restrict a user to a single command

User deploy may only restart nginx:

deploy ALL=(root) /usr/bin/systemctl restart nginx

Always use absolute paths in commands. A bare command name is rejected, and worse, a relative path can be defeated by manipulating PATH.

Q11. Grant several commands cleanly with aliases

When a user needs many commands, list them space-separated, or define a Cmnd_Alias for readability. Aliases come in four types — User_Alias, Runas_Alias, Host_Alias, and Cmnd_Alias — and alias names must be uppercase:

1. User_Alias ADMINS = tom, jerry, adam
2. Cmnd_Alias PROCS = /bin/kill, /usr/bin/killall, /usr/bin/pkill, /usr/bin/top
3. ADMINS ALL = PROCS

Now every user in ADMINS can run any command in PROCS. To target a system group instead of named users, prefix the group with %: %dba ALL=(oracle) ALL lets every member of the dba group act as oracle.

Q12. Allow a sudo command with no password prompt

Use the NOPASSWD tag — sparingly, because it weakens accountability:

adam ALL=(ALL) NOPASSWD: PROCS

Here adam runs the PROCS commands without being prompted. This is typically reserved for automation accounts or specific safe commands, never for blanket ALL access.

Security, auditing, and best practices

Q13. Why is sudo considered more secure than su?

• No shared root password. Users authenticate with their own credentials, so you can revoke one person without rotating root.
• Least privilege. You grant exactly the commands and target identities a role needs — impossible with su, which is all-or-nothing.
• Auditability. Every sudo invocation is logged (to /var/log/auth.log on Debian or /var/log/secure on RHEL via syslog), recording who ran what, where, and when.
• Timed re-authentication. By default sudo caches your credentials for about 5 minutes per terminal; after that it asks again.

Q14. How do you check what sudo access you have?

Run sudo -l. It lists the commands the current user may run and as whom, straight from the active policy. To clear the cached credential immediately, run sudo -k (kill the timestamp), which forces a password prompt on the next sudo.

Q15. What is the single most dangerous sudoers mistake?

Editing /etc/sudoers directly and introducing a syntax error. If the file is invalid, sudo refuses to run at all — and if you have no root password set (common on Ubuntu, where root is locked), you can be completely locked out. visudo exists precisely to prevent this by validating before save. If you are ever locked out, you boot into single-user/recovery mode or a live USB to repair the file.

Key Takeaways

• sudo runs one command with elevation using your own password; su starts a new shell as another user using that account's password.
• Always edit policy with sudo visudo or a /etc/sudoers.d/ drop-in — never a plain editor — to avoid locking yourself out.
• The sudoers rule format is user host=(run_as_user:group) command, and command paths must be absolute.
• Grant access via the sudo group (Debian/Ubuntu) or wheel group (RHEL/Fedora) rather than listing users one by one.
• Prefer sudo -i over su - for a root shell: no shared root password, full audit trail, and least-privilege control.

Frequently Asked Questions

Is sudo or su better for everyday administration?

sudo is the modern best practice. It avoids sharing the root password, logs every privileged action, and lets you grant access per command and per user. Most distributions now lock the root account and expect you to use sudo.

Why does sudo ask for my password and su asks for root's?

sudo verifies your identity against its policy, so it prompts for your password. su is logging you into the target account directly, so it must verify that account — meaning you need the root (or target user's) password.

How do I undo or remove a user's sudo access?

Remove them from the admin group with sudo gpasswd -d bob sudo (or wheel on RHEL), and delete any user-specific lines or drop-in files in /etc/sudoers.d/ using visudo. Have the user start a new session for the change to apply.

What does "user is not in the sudoers file" mean?

It means your account has no sudo authorization. A user with existing root or sudo rights must add you to the sudo/wheel group or write a rule for you via visudo.

For more Linux and sysadmin interview walkthroughs, subscribe to @explorenystream on YouTube.