Is Terraform declarative or imperative and is it suitable for DB restore procedures ?

Question: Is Terraform declarative or imperative and is it suitable for DB restore procedures ?   I'm working on developing procedures to integrate ad-hoc Restore procedures across multiple Cloud Database flavours - and working with Cloud Engineers to code our procedures.    

I'm not sure how to proceed with developing operational ad-hoc procedures such as Restores . 

Answer:   This is a recurring consideration , particuarly thinking  about operational procedures.    A typical example would be an RDS restore - typically recovered as a different  DBInstanceIdentifier from a specific recovery point . 

One of the concepts is understanding the difference between the declarative and imperative models.  An example of a declarative  instruction is " I want to create a new RDS instance into a specific AWS account with specific input variables - such as server class"  . An example of of an imperative instruction " Go to the backup storage , select a specific recovery point , and then recover at a specific time , based on the customers requirements"

There are consequences depending on which model to use . If you were to create a Terraform procedure (declerative)  requesting a specific Recovery point ,  if the recovery point did not exist - than the instruction would throw an error.     On the other hand - if the instruction was created using a CLI command , which I'd class as Imperative - if the recovery point did not exist an explicit error would occur.

It's clear from these examples - deciding on which approach to take in regards to Restores requires some thought.  

Let's look at a couple of examples   of how the  the Restore request would play out using different methods.

The first example - is an explicit AWS CLI command to recover a specific snapshot 

aws rds restore-db-instance-from-db-snapshot \
    --db-instance-identifier myrdspostgresql-instance \
    --db-snapshot-identifier myrdspostgresql-snapshot1\
    --db-instance-class db.m6g.large \

The second example is attempting to complete a similar step as above. Note : there is an explicit request for a specific snapshot , as opposed to the latest snapshot 

 
provider "aws" {
  region = "us-east-1"
}

# Get latest snapshot from production DB
data "aws_db_snapshot" "db_snapshot" {
    most_recent = false
    db_instance_identifier = "db-prod"
}
# Create new staging DB
resource "aws_db_instance" "db_uat" {
  instance_class       = "db.m6g.large"
  identifier           = "myrdspostgresql-instance "
  username             = "xxxxxxx"
  password             = "xxxxxxx"
  db_subnet_group_name = "db-private-subnet"
  snapshot_identifier  = "myrdspostgresql-snapshot1"
  vpc_security_group_ids = ["sg-xxxxxx"]
  skip_final_snapshot = true
}

In both cases we're requesting a specific restore recovery point reperesented by the snapshot identifier for a specific DB Instance. 

1) In the Terraform example - what would happen if that specific snapshot was no longer available? 

2) If you executed the CLI code - you would have to also create some extra post restore steps to maintain the original endpoint , etc . To then avoid configuration drift , you'd need to identify 

any configuration changes by running terraform plan. 

3) The other complexity is if you had an RDS failover - Terraform would not be aware of this and would a mnual correction be required ?

4) Things get even more complex when you think about how an RDS snapshot is recovered & how this change will interact with Terraform . These four steps is potential step by step approach on recovering an RDS

                  ->Restore snapshot to new database new-db1, with similar  configuration the original RDS
                  ->Modify original RDS to have a new DBidentifier like old-db1. Your endpoint will change , so your app will lose connectivity when AWS completes the modification.
                  -> Modify the new-db1 to have the original db identifier . This will change the endpoint to match the original endpoint.
                 ->Execute terraform plan and see whether there are any configuration changes. Update the new db to match the configuration in the current Terraform state.

These are some initial thoughts on AWS DB restore procedures and Terraform .