Shayn and Stewart:
No, not "good to know" since this information is absolutely false. The wording found in that SQL Server 2017 documentation stating that all SQLCLR code is considered "unsafe" (starting with SQL Server 2017, if "CLR strict security" is enabled, and it is by default), is misleading. It only means that all verification steps are processed, none are skipped, when loading SQLCLR assemblies, both at creation time (via CREATE ASSEMBLY / ALTER ASSEMBLY) and at runtime (when SQLCLR objects are accessed). Previously you could CREATE ASSEMBLY that contained "unsafe" code yet was marked as either SAFE or EXTERNAL_ACCESS, but it would fail at runtime if you either didn't have TRUSTWORTHY enabled (bad choice) or had not signed the assembly and had the matching signature-based Login that had been granted the UNSAFE ASSEMBLY permission. But if you mark your assembly as SAFE in SQL Server 2017 or 2019, then you will not be able to access the file system, network, etc.
I am working on a post right now that will clarify this and provide a simple example to prove that a SAFE Assembly, even with "CLR strict security" enabled, will not be able to access any external resource, let alone do something requiring the UNSAFE permissions set. I will post again once I have that blog post up.
Please either remove this question or provide an answer for people to choose that is correct (the sooner the better given that this question is spreading misinformation on a topic that is already flooded with misinformation). Currently all answer choices are incorrect; no correct option is available to choose. The actual correct answer (for the question as it is currently worded), is:
"No change from previous versions of SQL Server: EXTERNAL_ACCESS only allows for accessing external resources, and UNSAFE allows for accessing external resources, calling unmanaged code, and a few other things."
It should also be noted that the restriction imposed by "CLR strict security" is ignored if the database has TRUSTWORTHY enabled (another reason to not enable TRUSTWORTHY). However, this doesn't change the answer since both "CLR strict security" and TRUSTWORTHY affect what PERMISSION_SETs are allowed, not what can be done within those PERMISSION_SETs.
Take care, Solomon..