Is `~/Documents` a relative or an absolute path?
This is essentially a question about the definition of terms. So for your purposes, the answer is whatever LPIC wants. But we can come to some conclusions based on technical facts:
If you passed '~/Documents' to a system call, it would look for a directory named exactly ~ in the current directory (and probably fail). So, by the notion of pathnames used by the kernel, this is a relative path — but that's not what we meant.
~ is syntax implemented by the shell (and other programs which imitate it for convenience) which expands it into a real pathname. To illustrate, ~/Documents is approximately the same thing as $HOME/Documents (again, shell syntax). Since $HOME should be an absolute path, the value of $HOME/Documents is also an absolute path. But the text $HOME/Documents or ~/Documents has to be expanded by the shell in order to become the path we mean.
Thus if I wanted to be precise and consistent, I would say that ~/Documents is a fragment of shell-script which expands to an absolute path.
If the author was trying to catch you out by talking about that literal string (without shell expansion) as a path, then it's a relative path (mkdir -p './~/Documents'). Otherwise:
It's an absolute path, because resolving it doesn't depend on the process's current working directory. Relative path always means relative to the process's working directory. Or in the case of symlink targets, relative to the location of the symlink. (gcc -> gcc-5.2 vs. gcc -> /usr/bin/gcc-5.2). This matters for NFS-mounts and other cases where you can get to the same symlink via different absolute paths. e.g.
/net/tesla/home/peter/foo -> bar # always works from other machines
/net/tesla/home/peter/foo -> /home/peter/bar # references my home dir on the local machine, not tesla.
Debian will sometimes install symlinks to ../../doc/whatever/whatever, instead of an absolute symlink target, so it works when NFS mounted somewhere else, or when looking at a chroot without chroot(8)ing into it.
Every Unix process has its own cwd. The pwd command exists just to print it.
see: http://pubs.opengroup.org/onlinepubs/9699919799/functions/getcwd.html for more about changing directories with POSIX system calls.
As everyone else has said, ~ is expanded by the shell before the path is used for anything. Using ~/bin/myprog in a shell script will make it work differently for different users. The difference between ~/bin/foo and /home/peter/bin/foo is that one of them has hard-coded the location, while the other has parameterized it. It's an error (IMO) to call the ~ version a relative path.
Talking about things being "relative to an environment variable" is just confusing. It's bad practice to use different English-language meanings of terms that have specific technical meanings in the context you're using them in.
On a broken system, with HOME=a/relative/path, ~/foo would expand to a relative path. This would not be a usable setup at all.
If your $HOME is /home/white/, ~/Documents (same as $HOME/Documents) is expanded by the shell (see here for an explanation) to /home/white/Documents, which is an absolute path.
A relative path is one that does not start with a / (after shell expansion), like ../Documents or foo/bar
Some old shells don't expand ~ (the way bash, tcsh, zsh, etc. ... do); they would see ~/Documents as a relative path starting with ~; but you usually don't have directory name like ~ (but you might create one with mkdir '~', which I don't recommend).