The best way to unwrap the optional in java
I think you want flatMap. 
Those returns and braces are unnecessary noise.
I would consider not throwing but returning Optional&lt;UserConfiguration&gt; instead. Part of learning this style is realising that unwrapping is rarely necessary. At the call site, you can do something along the lines of update(user).ifPresentOrElse(...). [*]

public Optional&lt;UserConfiguration&gt; update(User user) {
    return user.getConfigurationId() // Optional&lt;UUID&gt;
        .flatMap(configurationId -&gt; userConfigurationRepository.findById(configurationId)) // Optional&lt;UserConfiguration&gt;
        .map(userConfiguration -&gt; updateUserConfiguration(userConfiguration)); // Optional&lt;UserConfiguration&gt;
}

However, if you insist on unwrapping, nothing's stopping you, technically.

public UserConfiguration update(User user) {
    return user.getConfigurationId() // Optional&lt;UUID&gt;
        .flatMap(configurationId -&gt; userConfigurationRepository.findById(configurationId)) // Optional&lt;UserConfiguration&gt;
        .map(userConfiguration -&gt; updateUserConfiguration(userConfiguration)) // Optional&lt;UserConfiguration&gt;
        .orElseThrow();
}

consider method references. Sometimes they make code more readable, other times they don't. But mostly yes.

public Optional&lt;UserConfiguration&gt; update(User user) {
    return user.getConfigurationId() // Optional&lt;UUID&gt;
        .flatMap(userConfigurationRepository::findById) // Optional&lt;UserConfiguration&gt;
        .map(this::updateUserConfiguration); // Optional&lt;UserConfiguration&gt;
}



[*] - Getting into this mindset would help you a lot when you will start working with other wrapper types that rely on the same abstractions, such as the standard library's Stream, RxJava, Spring 5-reactive stack / Project Reactor, or classes provided by the vavr library. Although possible, unwrapping some of these is considered a very bad idea, e.g. in case of RxJava and Reactor it is a blocking action which you want to avoid at all costs when writing reactive software. But even in the case of Optional, why not have the fact that the value might be missing captured by the type system rather that throwing Exceptions around that might be invisible up the stack until there is actually an issue.