Database Specialty - CloudFormation and Automation Flashcards

Question

CloudFormation Must Know Intrinsic Functions

Answer 1

* Ref * Fn::GetAtt * Fn::FindInMap * Fn::ImportValue * Fn::Join * Fn::Sub * Condition Functions (Fn::If, Fn::Not, Fn::Equals, etc…)

Answer 2

* The Fn::Ref function can be leveraged to reference * Parameters => returns the value of the parameter * Resources => returns the physical ID of the underlying resource (ex: EC2 ID) * The shorthand for this in YAML is !Ref DbSubnet1: Type: AWS: :EC2: :Subnet Properties: VpcId: !Ref MyVPC

Answer 3

* Attributes are attached to any resources you create * To know the attributes of your resources, the best place to look at is the documentation. * For example: the AZ of an EC2 machine!

Answer 4

* We use Fn::FindInMap to return a named value from a specific key * !FindInMap [ MapName, TopLevelKey, SecondLevelKey ]

Answer 5

* Import values that are exported in other templates * For this, we use the Fn::ImportValue function

Answer 6

* Join values with a delimiter * * This creates “a:b:c”

Answer 7

* Fn::Sub, or !Sub as a shorthand, is used to substitute variables from a text. It’s a very handy function that will allow you to fully customize your templates. * For example, you can combine Fn::Sub with References or AWS Pseudo variables!

Answer 8

* The logical ID is for you to choose. It’s how you name condition * The intrinsic function (logical) can be any of the following: * Fn::And * Fn::Equals * Fn::If * Fn::Not * Fn::Or Conditions: CreateProdResources: !Equals [ !Ref EnvType, prod]

Answer 9

* Stack Creation Fails: * Default: everything rolls back (gets deleted). We can look at the log * Option to disable rollback and troubleshoot what happened * Stack Update Fails: * The stack automatically rolls back to the previous known working state * Ability to see in the log what happened and error messages

Answer 10

* When you update a stack, you need to know what changes before it happens for greater confidence * ChangeSets won’t say if the update will be successful

Answer 11

* Nested stacks are stacks as part of other stacks * They allow you to isolate repeated patterns / common components in separate stacks and call them from other stacks * Example: * Load Balancer configuration that is re-used * Security Group that is re-used * Nested stacks are considered best practice * To update a nested stack, always update the parent (root stack)

Answer 12

* Helpful when stacks have different lifecycles * Use Outputs Export and Fn::ImportValue * When you need to pass export values to many stacks (VPC Id, etc…)

Answer 13

* Helpful when components must be re-used * Ex: re-use how to properly configure an Application Load Balancer * The nested stack only is important to the higher level stack (it’s not shared)

Answer 14

* Create, update, or delete stacks across multiple accounts and regions with a single operation * Administrator account to create StackSets * Trusted accounts to create, update, delete stack instances from StackSets * When you update a stack set, all associated stack instances are updated throughout all accounts and regions.

Answer 15

* AWS::RDS::DBInstance https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws- properties-rds-database-instance.html * Important Parameters: * DeleteAutomatedBackups: remove automated backups immediately after the DB instance is deleted. Default value: remove all automated backups * DeletionProtection: enable deletion protection on the DB in RDS. The database can’t be deleted while it has DeletionProtection on. * MasterUsername / MasterPassword: must be provided as text values (we’ll see how to handle that securely later on) * EnableIAMDatabaseAuthentication: can be enabled, does not replace Master username & password * DBClusterIdentifier: (optional) if the DB belongs to an Aurora DB cluster

Answer 16

* If Update Requires: Replacement: * New DB is created * Links are updated * Old DB is deleted * If a DB instance is deleted or replaced during an update, AWS CloudFormation deletes all automated snapshots. * However, it retains manual DB snapshots * During an update that requires replacement, you can apply a stack policy to prevent DB instances from being replaced

Answer 17

* Take a snapshot before updating an update. If you don't, you lose the data when AWS CloudFormation replaces your DB instance. To preserve your data: * Deactivate any applications that are using the DB instance so that there's no activity on the DB instance. * Create a snapshot of the DB instance * If you want to restore your instance using a DB snapshot, modify the updated template with your DB instance changes and add the DBSnapshotIdentifier property with the ID of the DB snapshot that you want to use. * After you restore a DB instance with a DBSnapshotIdentifier property, you must specify the same DBSnapshotIdentifier property for any future updates to the DB instance. * Update the stack. * DBSnapshotIdentifier is also useful for mass creating dev/test databases with some data from prod

Answer 18

* CloudFormation Stack Termination Protection: can’t delete the stack without removing it (but you can still update the stack) * CloudFormation Stack Policy: prevent updates to CloudFormation templates. * CloudFormation DeletionPolicy: what happens if a resource gets deleted * Delete: delete the resource (default behaviour for most resources) * Retain: do not delete the resources * Snapshot: (only to resources that support snapshot) snapshot then delete * The default CloudFormation behavior for RDS depends on DBClusterIdentifier : * If DBClusterIdentifier not specified (= non Aurora), CloudFormation will snapshot * If DBClusterIdentifier is specified (=Aurora), CloudFormation deletes the DB instance

Answer 19

* First create an AWS::RDS::DBCluster * Then add AWS::RDS::DBInstance * Default DeletionPolicy of RDS::DBCluster is Snapshot * Means if individual DBInstance are deleted, no snapshot is made (default) * If the DBCluster is deleted, a snapshot will be made * RDS::DBInstance will inherit configurations

Answer 20

* Parameters are referenced using !Ref * They can have 4 different sources: * (static) Given using the CLI / Management console * (static) Given using a flat file from local filesystem or S3 * (dynamic) From the SSM Parameter Store * (dynamic) From AWS Secrets Manager * The last two are the most secure way * Exam trap: you cannot pass in KMS encrypted parameters through * Use SSM Parameter Store or Secrets Manager instead!

Answer 21

* Retrieve a String (plaintext) or SecureString (KMS encrypted) from SSM Parameter Store at runtime! * Amazing to store environment specific variables * Hierarchical way of storing parameters * SSM CF parameters: will be resolved every time you run the template, does not work for SecureString. * Dynamic parameter pattern: '{{resolve:ssm:parameter-name:version}}’, you must specify the exact version, works for SecureString.

Answer 22

* Secrets rotation + integration with RDS = * Dynamic parameter pattern: '{{resolve:ssm:parameter-name:version}}’, you must specify the exact version * Neither Secrets Manager nor CloudFormation logs or persists any resolved secret value * Updating a secret in Secrets Manager does not automatically update the secret in CloudFormation * To manage updating the secret in your template, consider using version-id to specify the version of your secret. * {{resolve:secretsmanager:secret-id:secret- string:json-key:version-stage:version-id}

Answer 23

1. Create a AWS::SecretsManager::Secret * Specify GenerateSecretString to randomly generate a secret 2. Create an AWS::RDS::DBInstance that references that secret * Using dynamic references 3. Create a AWS::SecretsManager::SecretTargetAttachment * Link to Secrets Manager secret and the RDS database together * Will add RDS properties to Secret Manager JSON

Answer 24

4. Create a AWS::SecretsManager::RotationSchedule * It will create a Lambda function * You must do this after creating the secret attachment

Answer 25

* CloudFormation Drift: * See if the resource configurations have changed from the template over time * Stack Set: * Apply the same CloudFormation template into many accounts / regions * Change Set: * Evaluate the changes that will be applied before applying them (safety)