This is not a “clickbait” title, but an important consideration when it comes to developing technical solutions. Let me give you an example between two questions for SQL Server on-premises running on Windows.
Question 1: Does SQL Server allow you to set things like password complexity, password length, and the number of failed login attempts before the account is locked?
Question 2: Does SQL Server support things like password complexity, password length, and locking the account after a number of failed login attempts?
At first glance, the questions are similar. The difference in the questions is centered around whether or not SQL Server lets you set those values. SQL Server does not. SQL Server will use the Windows policies with regards to passwords (see the section on CHECK_POLICY). So while SQL Server support those elements, it doesn’t allow you to directly set them. Therefore, the answer to Question 1 is no while the answer to Question 2 is yes. If the goal is to ensure that proper password policies are enforceable, then SQL Server does that. Answering Question 1 without any further discussion will miss the goal.
So what happens if we get a question like question 1? It’s time for us to ask clarifying questions. We need to understand what the asker is trying to discover or verify. I’ve had engagements with IS auditors where Question 1 was asked. That causes me to stop and ask back something like, “Are you looking to see that logins created in SQL Server can have enforcement of strong password policies?” This gets to the root of what they are trying to understand. By asking this clarifying question, I get a chance to give them the complete answer, which is beyond what the auditor initially asked.
I’ve seen similar types of questions coming from developers. For instance, a typical question might be, “Have I got this query correct to use a CTE?” I can answer that question directly, it’s a simple yes or no, but I should ask, “What is this query supposed to do?” It may be they don’t need a CTE at all. But neither I nor the developer won’t know that unless I ask my question to understand what the developer is trying to do.
It’s often up to the person with the expertise to ensure the appropriate question is asked. There’s an old saying, “they don’t know what they don’t know.” And there’s another saying, “Anyone can have a brain fart.” So even if someone should also be an expert, it’s never a bad idea to ask the intent behind the initial question so we can ensure the right question is asked and properly answered. Don’t be afraid to spend the effort to ensure the right question is being asked.