The Repository Pattern is often implemented in a way so that the Repository uses the Strategy Pattern – but this not a core aspect of that Pattern.
The point of a Repository (in the Domain-Driven Design sense) is to provide an object that encapsulates the data access logic, so that the programmer can use the Repository as if it were an in-memory collection. This description involves objects, but does not rely on other OOP concepts such as interfaces or inheritance. If the Repository is related to one of the classic GoF OOP design patterns, it might be a Factory pattern since the repository creates the Entity objects when returning results from a query.
Instead of just letting a Repository behave as if it were an in-memory collection, it's possible to create a Repository interface so that you can have multiple implementations of the Repository in your code. There might be implementations that encapsulate different database technologies, for example a Postgres-Repository and a CouchDB-Repository, or an in-memory-Repository for use in unit tests. Then, each of these implementations could also be interpreted as a Repository-Strategy.
Instead of saying that a Repository necessarily is a Strategy, I'd rather say that it harmonizes very well with the Strategy pattern. Some articles such as the MSDN architecture suggestions that you quoted do suggest the use of these interfaces, and it is a de-facto best practice, and it is almost always done when using the Entity Framework. For example, such interfaces aid with dependency inversion and testability. The MSDN article notes:
As noted in an earlier section, it's recommended that you define and place the repository interfaces in the domain model layer so the application layer, such as your Web API microservice, doesn't depend directly on the infrastructure layer where you've implemented the actual repository classes.
So these interfaces aren't strictly necessary for using the repository pattern, but introducing these interfaces and combining Repositories with the Strategy Pattern definitely has some advantages.
Another way to look at this is that the Strategy pattern is a very generic behavioural pattern. Strategies are ubiquitous and sometimes barely worth mentioning when they are “just an interface”. From that viewpoint, a Repository interface is an application of the general Strategy idea to the specific problem domain of data access.