Are Availability Group Databases on a Secondary replica automatically set to read-only by the AG? I have read through the MS docs on read-only routing, but I am not talking about that.

Currently, if I execute an UPDATE against a database that is on a Secondary replica and is part of the Availability Group, I receive a message:

Msg 3906, Level 16, State 2, Line 6
Failed to update database "dbName" because the database is read-only.


My question is whether this configuration is established by default (and unavoidable) by virtue of the database being part of the AG and on a Secondary at the moment?

Some interesting extras:

The following SQL, run on that Secondary, shows I have UPDATE, ALTER and a whole lot more permissions against this database:

SELECT * 
FROM fn_my_permissions(null, 'DATABASE')   
ORDER BY subentity_name, permission_name;


The following SQL explicitly shows I have permission to UPDATE a table in that database:

SELECT * 
FROM fn_my_permissions('dbName.dbo.tblName', 'OBJECT')   
ORDER BY subentity_name, permission_name ;


In spite of this I am actually prevented from updating that table. This implies:


The output of fn_my_permissions is not strictly correct
The database "read-only" setting overrides individual permissions


I understand the setting in play is configured via:

ALTER DATABASE dbName SET READ_ONLY


and

ALTER DATABASE dbName SET READ_WRITE WITH NO_WAIT


The main reason for the question is to understand whether the "read only" configuration is a DBA/designer's responsibility during design and deployment of the AG, or an expected (and guaranteed?) feature by simple virtue of using an AG.
I would give the docs a good read. Particularly the section on availability replicas.


  Every availability replica is assigned an initial role-either the primary role or the secondary role, which is inherited by the availability databases of that replica. The role of a given replica determines whether it hosts read-write databases or read-only databases. One replica, known as the primary replica, is assigned the primary role and hosts read-write databases, which are known as primary databases. At least one other replica, known as a secondary replica, is assigned the secondary role. A secondary replica hosts read-only databases, known as secondary databases.


As can be seen above, each replica can either be read-only or read-write (secondary or primary respectively). In addition there can only be one primary (read-write) replica. When we refer to replica in this respect, we are referring to the database level. Each server can host multiple availability groups, with potentially mixed primary-secondary configuration.

The situation you are referring to with multiple read-write replicas is not supported by AlwaysOn Availability Groups, which are designed to meet High Availability and Read-Scale needs, not multi-master setups. You should look at two-way replication technologies to support this need.

As for the read-only setting itself, this is automatically set by the availability group, although it's worth saying that this is not the same setting as the "Database Read-Only" setting found in the database properties (or is_read_only in sys.databases), nor is it the same setting as the file group level read-only option.