Who decides if and when to release the Product Increment ?

What is the source of these PSM1 preparation questions? Not all sources for preparation material are equal and some have content based on old Scrum Guides or incorrect content.

The November 2017 Scrum Guide says that (emphasis mine):

The increment must be in useable condition regardless of whether the Product Owner decides to release it.

This means that, in that previous revision, your answer of "Product Owner" should be correct.

However, this was removed in the November 2020 Scrum Guide. Unfortunately, there isn't an explicit answer one way or the other in the November 2020 version.

I'm not convinced there is a singularly correct answer in all situations.

The Product Owner is accountable for maximizing value. The frequency at which new product Increments are released and made available for use by stakeholders has a direct impact on value. Therefore, the Product Owner should help guide the team toward achieving a release cadence that is appropriate for maximizing value in the team's current context. However, there are often procedural or technical barriers to releasing at the desired frequency. Developers would be the ones who need to overcome any of these barriers. Although the Product Owner may want a cadence, the Developers may not be able to achieve that cadence. Depending on the value of achieving the cadence, the work needed to reduce or eliminate barriers to release would have to be planned and executed by the team, taking away from other potentially valuable work.

The Product Owner and Developers would need to collaborate on understanding how to maximize value delivery with respect to releasing product Increments. However, I would expect that the guidance for the desired release schedule and frequency would ultimately come from the Product Owner, managing and conveying the needs of various stakeholders.

Once an Increment is Done the imperative is to "release" it, in that empirical feedback ought to be obtained. Either the PO or Developers could stop a release for these purposes from happening, if they saw an issue with value or quality. In so far as there is a release decision to be made in the first place, that's pretty much it.

Once an Increment is Done the imperative is to "release" it

I would disagree, an Increment should be releasable, but doesn't need to be released. 

To me, a release is a question of the customer value, and maximizing that value is the responsibility of the PO. Members of the Scrum Team have the power to "say no" to a release, by declaring a PBI not being "Done". But when a PBI is considered "Done", the PO must decide if the sum of the last completed Increments would deliver enough customer value to be released. 

when a PBI is considered "Done", the PO must decide if the sum of the last completed Increments would deliver enough customer value to be released

That's a decision gate. So think of it the other way around: if there isn't enough customer value for a "release" of some sort, then the PO could stop one from happening.

In Scrum decision gates are challenged, so as not to put empiricism in delay. Hence this gate, alluded to in an earlier version of the Scrum Guide (as Thomas pointed out), was subsequently removed.

To me, a release is a question of the customer value, and maximizing that value is the responsibility of the PO.

Can value be realized without releasing? Can validated learning happen without releasing? I agree that at least one increment must be potentially releasable by the end of every Sprint, but not releasing early and often puts a PO at a significant disadvantage. 

Members of the Scrum Team have the power to "say no" to a release, by declaring a PBI not being "Done".

This is a moot point, in my opinion. A PBI that isn't "Done" isn't part of the product Increment. It would be a different story if the commitment to the Definition of Done wasn't fulfilled, but that is a much different can of worms to open.

I believe the problem here is the definition of "release".  It can mean different things to different people and organizations.  I worked with a few teams where "release" meant to put it in an environment where feedback could be obtained.  That was often a staging environment prior to production that was available to people internal and external via specialized links.  I expect that was part of the reason for the change in the 2020 guide, but just my opinion with nothing to back it up. 

From the current Scrum Guide:

The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint.

Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint.

At least one increment each Sprint needs to be valuable, useful, and usable.  It has to be usable in order to obtain feedback.  It needs t be valuable and useful in order for the stakeholders to see a reason to provide feedback. The decision to release is not considered in the current Scrum framework. 

@Gözde, I'd be careful with the answers given for the questions contained in that study material.  While the questions might be good and valid, the answers that they provide may not.  I suggest studying the Scrum Guide and use all of the free assessments available here.  That is what I did and I was able to pass multiple certification exams.

The moment a Product Backlog item meets the Definition of Done, an Increment is born.

as from the 2020 ScrumGuide. With CI/CD pipelines, when code meets the definition of done it goes into the build and automated testing pipeline and out comes a new build version of the product (if all passes). This is not necessary how all companies work, but with automated and automation test pipelines the product is updated with the new increment in a way automatically. In these environments the reverse of the question is true, in that there needs to be a deliberate decision from the PO or the team to stop an increment from being released, otherwise the default is for the increment to go into the new product version and gets released with the next scheduled release date.

With this mechanism in mind, @Ian's explanation fits well. The gate keeping has been removed in the 2020 ScrumGuide and since current processes can be more automatic as is the case with CI/CD pipelines.