For a SOAP service both of these should end up in the catch-all, because soap service resolution requires that the POST payload match the service WSDL and for OPTIONS, GET, HEAD, DELETE, etc. there typically is no request body and therefore it does not resolve to the soap service and instead resolves to non-soap api based on URI resolution, which lands it in the catch-all. Once the request is there you can triage it, you may loop over the audit.details context variable and see if it contains a message indicating that soap service resolution failed (as seen in the audit viewer details). However, method not allowed is a bit more difficult. You would see same message because soap message comparis occurs before http method validation and if it passes messsage validation (or doesn't use it because it is not a soap service) and also URI resolution then when it fails method validation it will not execute the service policy, instead sending a generic L7 error message.
(for this reason I advise enabling all http methods on all non-soap services then doing method validation within the service)