EX200 Deploy, configure, and maintain systems Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Create /webcontent directory → Set SELinux context using semanage fcontext → Apply context with restorecon → Verify with ls -Z

  Why this is correct

  The correct sequence is methodical: first create /webcontent so a filesystem object exists, then use semanage fcontext to add a persistent rule mapping that path (with a regex like /webcontent(/.*)?) to httpd_sys_content_t. After the rule is stored in the SELinux policy, restorecon reads that rule and relabels the newly created directory and any contents to the specified type. Finally, ls -Z confirms that the files now carry the expected SELinux context, proving both the rule and its application succeeded.

• ✗

  Create /webcontent directory → Apply context with restorecon → Set SELinux context using semanage fcontext → Verify with ls -Z

  Why it's wrong here

  Running restorecon before defining the fcontext rule is futile because restorecon has no policy entry to reference—it will apply the default context for the parent directory, which is typically not httpd_sys_content_t. The subsequent semanage fcontext command does not retroactively relabel the already-restored directory; it only writes a rule for future restorecon runs. The verification with ls -Z at the end will show the default context, so the directory remains inaccessible to Apache despite the rule existing later.

• ✗

  Set SELinux context using semanage fcontext → Apply context with restorecon → Create /webcontent directory → Verify with ls -Z

  Why it's wrong here

  While semanage fcontext can be run before the directory exists (the rule is persistent), the subsequent restorecon runs when /webcontent is absent, so it has no target and completes with no effect. When the directory is then created, it inherits the default security context from its parent directory, not the custom httpd_sys_content_t defined in the fcontext rule. Since restorecon was already attempted too early, the final ls -Z reveals the wrong context, and the rule never gets applied to the actual directory.

• ✗

  Create /webcontent directory → Set SELinux context using semanage fcontext → Verify with ls -Z → Apply context with restorecon

  Why it's wrong here

  Setting the fcontext rule establishes the intended type in policy, but ls -Z only reads the existing on-disk context—it does not trigger relabeling. At this point in the sequence, the directory still carries its original default context, so the verification shows the old type, giving a misleading result. Despite running restorecon later, that premature verification invalidates the order: the evidence that the context was correctly applied is generated before application actually happens, so the final state is not verified as required.

Go deeper

Related to this question