How do the SQL command types fit together in one feature's lifecycle, from design to production?
In practice the categories line up with stages of a software lifecycle rather than sitting in isolation. DDL belongs to design and deploy: you create the table, add the columns, create the indexes, and later evolve them. DML belongs to runtime: every request that reads or writes rows is a SELECT, INSERT, UPDATE or DELETE. DCL belongs to operations, where a least-privilege role is granted to the application service and nobody else. TCL wraps the DML so that a multi-step change is atomic.
The useful mental model is shape, then content, then permission, then boundary. Schema first — you cannot insert into a table that does not exist yet. Rows second, because a constraint on the schema is what makes the row writes safe. Permissions third, because you want the role to exist before the deploy that starts using it. And the transaction boundary last, sitting around the group of row changes that must succeed or fail together.
What makes this worth knowing in an interview is that the boundaries are not symmetrical. DDL is coarse-grained and often irreversible — dropping a column loses the data, and in several engines the statement is auto-committed, so it cannot be rolled back with the row changes around it. DML is fine-grained and transactional. DCL is coarse-grained and usually takes effect at connection time. TCL is the only category that has no effect of its own; it purely changes what happens to the DML around it.
A second observation that separates strong candidates: the categories do not tell you whether a statement is safe. A DELETE is DML and fully transactional, but a DELETE without a WHERE clause still wipes the table. Transactionality and correctness are separate properties, and a good answer mentions both.