ExamFinch.com My Study

Study guide

18.4 Configure Privileged Access

Practice this exam

Red Hat Certified System Administrator RHCSA

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current Exam Facts 1.2 Lab Setup & Performance-Based Study Strategy

2 Essential Tools: Shell, Redirection & Text Analysis

2.1 Shell Prompt and Command Syntax 2.2 Input-Output Redirection and Pipes 2.3 grep and Regular Expressions for Text Analysis

3 Essential Tools: Remote Access, Users & Text Editing

3.1 Access Remote Systems Using SSH 3.2 Log In and Switch Users in Multiuser Targets 3.3 Create and Edit Text Files

4 Essential Tools: Files, Links & Archives

4.1 Create, Delete, Copy, and Move Files and Directories 4.2 Hard and Soft Links 4.3 Archive and Compress with tar, gzip, and bzip2

5 Essential Tools: Permissions & System Documentation

5.1 List, Set, and Change Standard ugo/rwx Permissions 5.2 System Documentation: man, info, and /usr/share/doc

6 Manage Software: RPM and Flatpak

6.1 Configure Access to RPM Repositories 6.2 Install and Remove RPM Software Packages 6.3 Configure Access to Flatpak Repositories 6.4 Install and Remove Flatpak Software Packages

7 Create Simple Shell Scripts

7.1 Conditional Execution: if, test, and [] 7.2 Looping Constructs for Files and Input 7.3 Process Script Inputs ($1, $2, and Beyond) 7.4 Process Shell Command Output in Scripts

8 Operate Running Systems: Boot and Recovery

8.1 Boot, Reboot, and Shut Down a System Normally 8.2 Boot Systems into Different Targets Manually 8.3 Interrupt the Boot Process to Gain Access

9 Operate Running Systems: Processes and Tuning

9.1 Identify and Kill CPU/Memory Intensive Processes 9.2 Adjust Process Scheduling 9.3 Manage Tuning Profiles

10 Operate Running Systems: Logs, Services & File Transfer

10.1 Locate and Interpret System Log Files and Journals 10.2 Preserve System Journals 10.3 Start, Stop, and Check Status of Network Services 10.4 Securely Transfer Files Between Systems

11 Configure Local Storage: Partitions and LVM

11.1 List, Create, and Delete Partitions on GPT Disks 11.2 Create and Remove Physical Volumes 11.3 Assign Physical Volumes to Volume Groups 11.4 Create and Delete Logical Volumes

12 Configure Local Storage: Mounting and Expansion

12.1 Mount File Systems at Boot by UUID or Label 12.2 Add Partitions, Logical Volumes, and Swap Non-Destructively

13 Create and Configure File Systems: Local FS and Permissions

13.1 Create, Mount, and Use VFAT, ext4, and XFS File Systems 13.2 Extend Existing Logical Volumes 13.3 Diagnose and Correct File Permission Problems

14 Create and Configure File Systems: NFS and autofs

14.1 Mount and Unmount Network File Systems Using NFS 14.2 Configure autofs

15 Deploy and Maintain: Scheduling, Services & Targets

15.1 Schedule Tasks with at, cron, and systemd Timers 15.2 Start, Stop, and Enable Services at Boot 15.3 Configure Systems to Boot into a Specific Target

16 Deploy and Maintain: Time, Software Updates & Bootloader

16.1 Configure Time Service Clients 16.2 Install and Update Software from CDN, Remote Repos, and Local Files 16.3 Modify the System Bootloader

17 Manage Basic Networking

17.1 Configure IPv4 and IPv6 Addresses 17.2 Configure Hostname Resolution 17.3 Configure Network Services to Start Automatically at Boot 17.4 Restrict Network Access Using firewalld and firewall-cmd

18 Manage Users and Groups

18.1 Create, Delete, and Modify Local User Accounts 18.2 Change Passwords and Adjust Password Aging 18.3 Create, Delete, and Modify Local Groups and Memberships 18.4 Configure Privileged Access

19 Manage Security: Firewall, umask & SSH Keys

19.1 Configure Firewall Settings with firewall-cmd and firewalld 19.2 Manage Default File Permissions 19.3 Configure Key-Based Authentication for SSH

20 Manage Security: SELinux Modes and Contexts

20.1 Set Enforcing and Permissive Modes for SELinux 20.2 List and Identify SELinux File and Process Contexts 20.3 Restore Default File Contexts

21 Manage Security: SELinux Ports and Booleans

21.1 Manage SELinux Port Labels 21.2 Use Boolean Settings to Modify SELinux Settings

18.4 Configure Privileged Access

Key Takeaways Explain This Topic AI

Privileged access on RHCSA is configured primarily with sudo policy and admin group membership, not by casually sharing the root password.

On RHEL, membership in the wheel group typically grants full sudo via the default %wheel rule—add users with usermod -aG wheel and verify with id and sudo -l.

Edit sudoers only through visudo (visudo -f /etc/sudoers.d/name for drop-ins) so syntax is checked before the policy goes live.

Prefer /etc/sudoers.d/ drop-in files with safe mode 0440 and simple filenames; use absolute command paths and NOPASSWD only when the task requires them.

Verify with sudo -l -U username from root and with a fresh login session for the user so supplementary group membership is active.

Last updated: August 2026

18.4 Configure Privileged Access

Quick Answer: Grant admin-style rights with sudo . On RHEL, add trusted users to the wheel group (often already allowed in the default sudoers policy). For custom rules, create drop-in files under /etc/sudoers.d/ and edit only with visudo (for example visudo -f /etc/sudoers.d/ops ). Never hand-edit sudoers unsafely. Verify with id , groups , and sudo -l -U user .

What EX200 means by privileged access

The objective configure privileged access centers on sudo : controlled, audited elevation rather than sharing the root password. Typical tasks:

  • “Allow alice to run any command as root via sudo.”
  • “Add bob to the wheel group.”
  • “Create a sudoers rule so deploy can run /usr/bin/systemctl restart httpd without a password.”
  • “Ensure operators use sudo rather than direct root login.”

You must leave persistent policy in group membership and/or sudoers files that survive reboot.

How sudo works (practical model)

User runs sudo command .

sudo consults policy ( /etc/sudoers and /etc/sudoers.d/* ).

May prompt for the invoking user’s password (not root’s), depending on policy.

Runs the command with elevated privileges if allowed.

  • Logs the attempt (journal/ /var/log/secure depending on configuration). sudo id
  • sudo -l # list your privileges
  • sudo -l -U alice # list privileges for alice (as root)
  • The wheel group on RHEL
  • RHEL’s default /etc/sudoers typically contains a rule similar to: %wheel ALL=(ALL) ALL

Meaning: members of group wheel may run all commands as any user (commonly used as all-root admin rights) on all hosts, usually with password .

  • Sometimes a NOPASSWD variant is present but commented : # %wheel ALL=(ALL) NOPASSWD: ALL
  • Exam pattern A (most common): add the user to wheel . sudo usermod -aG wheel alice
  • id alice
  • getent group wheel

# re-login as alice, then:

  • sudo -l
  • sudo whoami # expect root
  • Because supplementary groups require a new session , test with a fresh login or: sudo -u alice -i
  • # then sudo -l
  • Or from root: sudo -l -U alice

Do not use usermod -G wheel alice without -a unless you intend to wipe other supplementary groups.

visudo: the only comfortable editor path

visudo locks the file, opens an editor, and syntax-checks before installing the change. A broken sudoers can lock out elevation—disastrous on a remote exam host. sudo visudo # edit main /etc/sudoers

sudo visudo -f /etc/sudoers.d/ops # edit/create a drop-in safely # Validate a file without full interactive intent when supported

  • sudo visudo -cf /etc/sudoers
  • sudo visudo -cf /etc/sudoers.d/ops

If visudo reports syntax errors, fix them before saving/quitting . Do not force a broken file into place.

Editor selection

visudo uses EDITOR / VISUAL or a compiled default (often vi ). Under time pressure: sudo EDITOR=vim visudo -f /etc/sudoers.d/ops

  • # or
  • sudo EDITOR=nano visudo -f /etc/sudoers.d/ops
  • /etc/sudoers.d drop-ins (preferred for custom rules)

Best practice on RHEL: leave the distribution /etc/sudoers mostly alone; add drop-in files: ls -l /etc/sudoers.d

  • sudo visudo -f /etc/sudoers.d/rhcsa-ops
  • Main sudoers includes the directory (typically): #includedir /etc/sudoers.d
  • File naming and permissions

Prefer simple names without dots and tildes that sudo might ignore (avoid names containing . in some policies—RHEL documents ignoring files with ~ or . in certain cases; use names like ops , deploy , 10-alice ).

Permissions should be 0440 (visudo usually sets safe modes).

  • Owner root:root . sudo ls -l /etc/sudoers.d
  • # -r--r-----. 1 root root ... ops

If you create a file with tee instead of visudo, fix mode and always validate : echo 'alice ALL=(ALL) ALL' | sudo tee /etc/sudoers.d/alice

  • sudo chmod 440 /etc/sudoers.d/alice
  • sudo visudo -cf /etc/sudoers.d/alice

Prefer visudo -f so syntax check is automatic.

  • Sudoers rule syntax (enough for EX200)
  • Generic form: who where = (as_whom) commands
  • Common practical lines: # User alice may run anything as root (password required)
  • alice ALL=(ALL) ALL
  • # Group operators (% means group)
  • %operators ALL=(ALL) ALL
  • # NOPASSWD for all commands (powerful—only if task requires)
  • alice ALL=(ALL) NOPASSWD: ALL
  • # Narrow command list
  • deploy ALL=(root) /usr/bin/systemctl restart httpd, /usr/bin/systemctl status httpd
  • # NOPASSWD for specific commands only
  • deploy ALL=(root) NOPASSWD: /usr/bin/systemctl restart httpd
  • Token Meaning
  • alice User name
  • %wheel Group wheel
  • First ALL Hosts (ALL on single exam hosts)
  • (ALL) or (root) Run-as users
  • ALL commands Any command
  • Full path Exact command path allowed
  • NOPASSWD: No password prompt for following commands

Use absolute paths for command restrictions ( /usr/bin/systemctl , not bare systemctl ). Find paths with command -v systemctl . command -v systemctl

command -v dnf

Cmnd_Alias / User_Alias (awareness) Cmnd_Alias SERVICES = /usr/bin/systemctl restart httpd, /usr/bin/systemctl reload httpd

deploy ALL=(root) SERVICES

Aliases help larger policies; for one-line exam tasks, a direct rule is enough.

wheel vs explicit user rule

  • Approach When to use
  • usermod -aG wheel user Task says wheel, or full admin via default %wheel rule
  • Drop-in user ALL=(ALL) ALL Task wants sudo rights without mentioning wheel, or wheel policy is unavailable
  • Narrow command rules Task limits which commands may run elevated
  • NOPASSWD Only when the task explicitly requires passwordless sudo

If the default %wheel line is commented out (unusual but possible on customized images), adding to wheel silently does nothing until the rule exists—check: sudo grep -E '^[^#].*wheel' /etc/sudoers /etc/sudoers.d/* 2>/dev/null

sudo visudo -c

Then either uncomment via visudo (carefully) or add an explicit drop-in rule.

  • Verifying privileged access id alice
  • groups alice
  • getent group wheel
  • sudo -l -U alice
  • As the user (new session): sudo -l
  • sudo id
  • sudo cat /etc/shadow | head -n 1 # only if policy allows ALL; proves elevation

Negative test for restricted rules: ensure disallowed commands fail.

Root account vs sudo

Direct root login may be restricted over SSH ( PermitRootLogin )—a security topic.

su - switches to root if you know root’s password.

sudo -i or sudo -s gives a root shell if policy allows.

EX200 “privileged access” configuration almost always means sudo policy / wheel , not re-enabling insecure root SSH. sudo -i # root login shell if permitted

  • sudo -s # elevated shell
  • su - # needs root password
  • Logging and troubleshooting sudo journalctl -b | grep -i sudo | tail
  • sudo grep sudo /var/log/secure | tail

Common failures:

User not in allowed group / no matching rule.

Password wrong (user password).

Command path not matching restricted rule.

Typo in sudoers— visudo should have caught it.

Testing from a session that has not refreshed group membership.

  • Exam workflows
  • Workflow A — Full admin via wheel sudo usermod -aG wheel alice
  • id alice
  • sudo -l -U alice
  • # require alice to re-login for interactive group membership
  • Workflow B — Explicit ALL rule in sudoers.d sudo visudo -f /etc/sudoers.d/alice

# add:

  • # alice ALL=(ALL) ALL
  • sudo visudo -cf /etc/sudoers.d/alice
  • sudo -l -U alice
  • Workflow C — Passwordless full sudo (only if required) sudo visudo -f /etc/sudoers.d/alice-nopasswd
  • # alice ALL=(ALL) NOPASSWD: ALL
  • sudo -l -U alice
  • Workflow D — Limited command command -v systemctl
  • sudo visudo -f /etc/sudoers.d/deploy
  • # deploy ALL=(root) NOPASSWD: /usr/bin/systemctl restart httpd
  • sudo -l -U deploy
  • Workflow E — Group-based operators group sudo groupadd -f operators
  • sudo usermod -aG operators bob
  • sudo visudo -f /etc/sudoers.d/operators
  • # %operators ALL=(ALL) ALL
  • sudo -l -U bob
  • Workflow F — Repair broken sudoers (prevention)

Always edit with visudo. If you are still root in a session and validation fails, fix the drop-in with visudo -f immediately—do not log out while sudo is broken if you lack another root path.

Security hygiene on the exam

Prefer least privilege when the task specifies exact commands.

Do not set chmod 777 on sudoers files.

Do not leave world-writable /etc/sudoers.d entries.

Avoid NOPASSWD: ALL unless asked—it is easy to over-grant.

Keep a root shell only as needed; finish configuration and verify as the named user.

Common traps

usermod -G wheel without -a removing other groups.

Editing /etc/sudoers with plain vim and introducing a syntax error.

Creating /etc/sudoers.d/alice.conf style names that may be ignored due to dots—prefer alice or 10-alice .

Forgetting absolute paths in command-limited rules.

Testing sudo in a session that lacks new wheel membership until re-login.

Assuming wheel works when the %wheel line is commented out .

Wrong permissions on drop-in files (must not be writable by non-root).

Writing rules for the wrong username (typo).

Using root’s password mental model—sudo wants user password by default.

Skipping sudo -l -U user verification.

Relationship to other sections

18.1 / 18.3: users and wheel /custom groups must exist first.

18.2: sudo password prompts follow user password state (locked users cannot sudo interactively).

SSH objectives: remote admin often uses key login plus sudo.

Service management: limited sudo rules often wrap systemctl for app operators.

Security chapters: firewall and SELinux still apply to actions taken via sudo.

Section checkpoint

You should elevate with sudo , grant broad rights via the wheel group when appropriate, author custom policy under /etc/sudoers.d/ using visudo , write correct user/group and NOPASSWD/command rules with absolute paths, avoid destructive group replacements, and verify with id , getent group wheel , and sudo -l -U user . That fulfills EX200 privileged access configuration on RHEL 10.