Deploy, configure, and maintain systems →hardMultiple ChoiceObjective-mapped

EX200 Deploy, configure, and maintain systems Practice Question

Exhibit

Refer to the exhibit.

```
$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        20G   15G  5.0G  75% /
tmpfs           1.5G  2.3M  1.5G   1% /dev/shm
/dev/sdb1       100G   10G   90G  10% /data

$ ls -ld /data
drwx------. 6 root root 4096 Jan 1 12:00 /data
```

Refer to the exhibit. A user 'alice' is unable to write to /data directory. What is the most likely reason?

⚠ Common exam trap

Many exam-takers assume ownership by root (Option C) is the sole reason for denial, overlooking that permissions (Option A) are the actual gatekeeper; Red Hat exams test whether you understand that 'root ownership' does not block a non-root user if the 'others' permission allows write.

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 directory permissions restrict access

The exhibit (not shown here) likely displays directory permissions such as 'drwxr-xr-x' or 'drwx------' that do not grant write access to the user 'alice'. In Linux, the write permission (w) on a directory controls whether a user can create, delete, or rename files within it. Since 'alice' lacks write permission on /data, she cannot write to it, regardless of ownership or filesystem space.

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 directory permissions restrict access
Why this is correct
With mode 700 (drwx------), only the directory's owner has read, write, and execute permissions. Alice is neither root nor the owning UID, so for her the directory falls under 'others' with no permission bits set. Since creating or modifying a file requires write (and execute) permission on the directory itself, her write attempt is denied. This is exactly why the effective access is 'Permission denied'.
✗
The filesystem is nearly full
Why it's wrong here
A filesystem at 90% or even 99% capacity is irrelevant when 90G is free; write permission checks happen before any space allocation. Writing to a directory consumes space for a new directory entry, and an 'out of space' condition would typically surface as ENOSPC or a quota error, not as a permission denial. The reported 90G free clearly rules out a full filesystem as the cause.
✗
The directory is owned by root and alice is not root
Why it's wrong here
Unix permission evaluation first identifies the requester's relationship to the object — owner, group member, or other — but it is the mode bits that ultimately grant or deny access. Alice being a non-owner does not by itself prevent access, because group or other permissions could allow writing; for example, mode 770 would let group members write. In this case, the directory is set to 700, so 'others' (Alice) have no write permission, meaning the restrictive mode — not simple ownership — is what blocks her.
✗
The directory has ACLs preventing access
Why it's wrong here
The ls -l output shown in the exhibit has no '+' character after the permission string; a POSIX ACL, if present, is always indicated by a trailing plus sign, as in drwxrwx---+. Without that marker, only standard mode bits are in effect, and no ACL entries are masking or augmenting them. Therefore, the denial is fully explained by the ordinary 700 mode, not by any ACL rule.

Go deeper

EX200 Deploy, configure, and maintain systems Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question