# on 06-Jun-2019 (Thu)

#### Flashcard 4009044086028

Question
In terraform, a module is a collection of *.[...] files kept together in a directory. The root module is built from the configuration files in the current working directory when Terraform is run, and this module may reference child modules in other directories, which can in turn reference other modules, etc.
*.tf

status measured difficulty not learned 37% [default] 0

#### Flashcard 4009107524876

Question
In terraform, declare variable "cidrs" in your *.tf file, assuming its value will be a list
variable "cidrs" {
default = []
}

OR:

variable "cidrs" {
type = "list"
}

status measured difficulty not learned 37% [default] 0

#### Flashcard 4009122204940

Question
In terraform, if you have some values that repeat all over the place in the configs and you want an easy way to set their value in one place you can use local values/variables. With that in mind write code to setup the following local values/variables in your *.tf file:

default_name_prefix = "${var.project_name}-web" name_prefix = "something" Answer locals { default_name_prefix = "${var.project_name}-web"
name_prefix         = "something"
}

^^ note the use of the locals block type (un-named block) to decalre and assign all the local variables.

^^^ note that these values can be accessed in the rest of the *.tf configs, using the local.* syntax (e.x. "\${local.name_prefix}")

status measured difficulty not learned 37% [default] 0

#### Flashcard 4123542818060

Question
Considerations for which risk characteristics to use
[default - edit me]

status measured difficulty not learned 37% [default] 0

#### pdf

cannot see any pdfs

#### Flashcard 4123543866636

Question
[default - edit me]
1. Relationship of Risk Characteristics & Expected Outcomes 2. Causality 3. Objectivity 4. Practicality 5. Applicable Law 6. Industry Practices 7. Business Practices

status measured difficulty not learned 37% [default] 0

#### pdf

cannot see any pdfs

#### Annotation 4123554352396

 choose to use functions as fundamental building blocks because everyone encounters functions in pre-algebra and because the simplest programs are just such functions.

Preface
f server and client components. Hence any reasonably complete program consists of many building blocks: some deal with input, some create output, while some bridge the gap between those two. We <span>choose to use functions as fundamental building blocks because everyone encounters functions in pre-algebra and because the simplest programs are just such functions. The key is to discover which functions are needed, how to connect them, and how to build them from basic ingredients. In this context, “systematic program design” refers to a mix of two

#### Annotation 4123556711692

 Iterative Refinement addresses the issue that problems are complex and multifaceted. Getting everything right at once is nearly impossible.

Preface
generic questions from the design process and thus drive the novice to correct himself or herself. And this self-empowering process is the key difference between programming and program design. <span>Iterative Refinement addresses the issue that problems are complex and multifaceted. Getting everything right at once is nearly impossible. Instead, computer scientists borrow iterative refinement from the physical sciences to tackle this design problem. In essence, iterative refinement recommends stripping away all inessen

#### Annotation 4123558284556

 In this sense, a programmer is a miniscientist. Scientists create approximate models for some idealized version of the world to make predictions about it. As long as the model’s predictions come true, everything is fine; when the predicted events differ from the actual ones, scientists revise their models to reduce the discrepancy. In a similar vein, when programmers are given a task, they create a first design, turn it into code, evaluate it with actual users, and iteratively refine the design until the program’s behavior closely matches the desired product

Preface
s and re-solves the expanded problem, using the existing solution as much as possible. A repetition, also called an iteration, of these refinement steps eventually leads to a complete solution. <span>In this sense, a programmer is a miniscientist. Scientists create approximate models for some idealized version of the world to make predictions about it. As long as the model’s predictions come true, everything is fine; when the predicted events differ from the actual ones, scientists revise their models to reduce the discrepancy. In a similar vein, when programmers are given a task, they create a first design, turn it into code, evaluate it with actual users, and iteratively refine the design until the program’s behavior closely matches the desired product. This book introduces iterative refinement in two different ways. Since designing via refinement becomes useful even when the design of programs becomes complex, the book introduces the

#### Annotation 4123559857420

 “systematic program design” refers to a mix of two concepts: design recipes and iterative refinement.