TL;DR: State holds the resource address to provider ID mapping, persisted managed-resource attributes, and the dependency graph plus provider and serial metadata. The attribute values are the problem: many values returned by a provider are persisted, including generated passwords and connection strings, so the file is a credential store and has to be treated as one.
How to approach it
Give the three things quickly, then spend the answer on the consequence. The question is phrased to test whether you have thought about state as an artifact with an access-control story, which is what actually goes wrong.
A strong answer
Three things, concretely.
The mapping. Your configuration says aws_db_instance.primary; the provider knows db-abc123. Nothing in the code or the cloud connects those two facts, so state is the ledger that does. This is why deleting a resource block destroys the resource rather than orphaning it, and why a lost state file means the next plan proposes to create everything you already have.
The attributes. Managed attributes that the provider persists, including potentially sensitive values. This is what lets a plan be computed without querying every resource, and it is why state is sensitive. A generated database password, an access key, a connection string, a private key: may appear in state. Supported ephemeral values and write-only arguments are exceptions; verify the Terraform and provider versions. Marking a variable sensitive hides it from CLI output and changes nothing in the file.
The metadata. Dependency ordering so destroys happen in reverse, provider addresses and resource schema versions (the dependency lockfile selects provider package versions), a serial number that increments per write, and a lineage identifier. The serial is what makes locking meaningful and what makes two divergent state files impossible to merge by hand.
So the operating consequences. State belongs in a remote backend with encryption at rest and access restricted to the pipeline identity plus a very small group of humans, never in the repository, and never in a bucket that is world-readable inside the company. It needs locking, because two concurrent applies produce interleaved writes and a ledger matching neither reality nor either intention: enable native S3 locking with use_lockfile = true; the older DynamoDB locking path is deprecated. It needs versioning on the bucket, so a trusted snapshot is available for recovery. Reconcile that snapshot with resources changed since it was written before allowing an apply. OpenTofu added client-side state encryption, which is a genuine improvement over relying on the backend alone and worth naming if the interviewer is comparing the two.
The honest recovery answer, if asked: with no backup you re-import every resource by hand, one terraform import or import block at a time, verifying against a plan that eventually shows zero changes. The duration depends on inventory, import support and configuration quality, and that is the real argument for versioned remote state.
What interviewers probe next
"Does marking a variable sensitive keep it out of state?" No. It suppresses CLI and log output only. Sensitivity alone does not omit the value; ephemeral/write-only handling is a separate capability.
"What does the serial do?" It increments on every write and lets the backend detect a stale write. It is also why hand-editing state is dangerous: change contents without understanding lineage and serial and you get a file the backend accepts and Terraform misreads.
"How would you avoid secrets in state at all?" Stop having the provider generate them. Create the credential in a secrets manager and have the application read it at runtime, so Terraform manages the secret's existence rather than its value.
Common mistakes
Describing state as a performance cache. It is the identity ledger, and calling it a cache leads directly to the belief that deleting it is recoverable.
Not knowing attribute values are stored, which is the single most consequential fact about the file.
Recommending state in Git. It contains secrets, it changes on every apply, and it cannot be merged.
Sources: Sensitive values and state, S3 locking.