If an ASP.NET web application uses LINQ to persist business objects in a SQL Server database, LINQ may have been configured without the programmer ever seeing or setting any connection strings. It can therefore be non-obvious how to point the business objects at a different instance of the same (same-schema) database, because it is not obvious where the connection string is set.
It is set in the web.config file (for desktop applications, in app.config). So if a web application needs to use different DEV, TEST, and PROD instances of a business database, web.config can be modified to point the LINQ classes to a different instance.
This is pretty simple, and fundamental to using LINQ in a business setting, but it is a piece of trivia which, if not known, can lead to much head-scratching.
I don't have a lot to say, but this is my little bit.