Play Console's content-rating questionnaire ("All Other App Types -> Downloaded App") ends with nine User Content Sharing questions. Two of them ask whether the app can block users or UGC, and whether it can report users or UGC. It is natural to treat these as rating inputs — answer honestly, accept a slightly higher age band, move on. That reading is wrong, and it is the expensive kind of wrong.
Those two answers are read against the User Generated Content policy, which is prescriptive about what you must ship:
Apps that provide access to publicly accessible UGC, such as social networking apps and blogger apps, must implement in-app functionality to report users and content, and to block users.
UGC features that enable 1:1 user interaction with specific users (for example, direct messaging, tagging, mentioning, etc.) must provide an in-app functionality for blocking users.
So a truthful "No" to either question, next to a truthful "Yes" on "users can interact" and "users can share UGC", is a signed statement that the app does not meet policy. The questionnaire is where the two facts get put side by side. Enforcement is on the declaration-versus-behaviour discrepancy, so lying is worse than the gap.
The clause structure tells you what to build, and the two clauses are not the same requirement. Public UGC (a comment thread every signed-in user can read, a publishable profile or document) pulls in report and block. Private-but-1:1 interaction (direct messages, invite-scoped chat) pulls in block only. Map every user-to-user surface in the shipped artifact to one of those two buckets before deciding scope. An app can be entirely default-private and invite-only and still land in the first bucket because of one public comment surface.
Two practical traps:
A bug reporter is not content reporting, and an email address is not in-app. Both are easy to mistake for compliance. A "Report a problem" button that files an engineering ticket does not let a user report another user's post, and "email us at support@" in an acceptable-use policy is explicitly out-of-app.
Audit the shipped artifact, not the codebase. For a webview or hybrid app, what matters is what is reachable in the mobile shell. In our case a public Q&A board looked like a UGC surface in a mobile feed but rendered titles in plain non-clickable containers with no composer, while the feature that actually created public UGC on mobile was a news-digest comment thread nobody had listed as a social surface. Grep for the composer, not the feature name.
Sequencing, because it bites: the questionnaire must be true of the build you upload. If reporting is planned but unshipped, either land it and take the questionnaire once, or answer No now to unblock the other declarations and re-take the questionnaire afterwards. The questionnaire is re-takeable and the App content declarations stay editable until the app is sent for review, so there is no reason to guess forward.
Also worth knowing while you are in these forms: separate questions about the same subject want different answers. "Users can share their location with other users" is about a user-to-user feature and is No for most apps, while the Data safety form's "approximate location" item covers IP-inferred geo for analytics and is Yes for anything using a hosted analytics product that enriches on ingest. Answering both from the same mental model produces a contradiction between two forms a reviewer reads together.