As written, your request is impossible.
As I wrote in your previous iteration of this question, SObject describe information gives you access to the SObject's metadata (the name of the SObject, record type info, field metadata, if the SObject is creatable, etc...). It does not give you access to the data, the actual records of those SObjects.
If you need to use actual records of your Resource__c SObject, then you must query for them. There is no way around that fact.
While you could create Resource__c records in-memory (and not insert them), that would largely defeat the purpose of having an SObject. A more approprite choice here would be to make it an Apex class instead.
If you want to avoid hard-coding this information (so that changes to the data do not absolutely need a deployment), then the more appropriate choice would be to use a Custom Metadata Type. While .getAll() and .getInstance() almost certainly do run a query behind the scenes (to build an internal cache), it does not count against the SOQL query limit. Even if you explicitly query against a Custom Metadata Type, it does not count against the SOQL query limit (though in this case it does contribute to the query row limit).
If you do go with the Custom Metadata Type approach, be aware that reliably testing your code means that you should create a "proxy" class (and use it instead of calling .getAll() or .getInstance() directly). This allows you to inject data specific to your test, which is helpful for testing things that should generate exceptions as well as running the test in orgs that have no records of that Custom Metadata Type (because Custom Metadata Type records are metadata, we cannot insert new __mdt records in a test).
After you get over that hurdle, doing the actual comparison sounds like a job for a Set.
