1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55

Execution Plan
    Terraform has a "planning" step where it
    generates an execution plan.

    The execution plan shows what Terraform
    will do when you call apply.

    This lets you avoid any surprises when
    Terraform manipulates infrastructure.

    See also:
        vim +/"Plan (verb)" "$NOTES/ws/terraform/glossary.txt"
        vim +/"Plan (noun, 1)" "$NOTES/ws/terraform/glossary.txt"

Resource Graph
    Terraform builds a graph of all your
    resources, and parallelizes the creation
    and modification of any non-dependent
    resources.

    Because of this, Terraform builds
    infrastructure as efficiently as possible,
    and operators get insight into
    dependencies in their infrastructure.

Change Automation
    Complex changesets can be applied to your
    infrastructure with minimal human
    interaction.

    With the previously mentioned execution
    plan and resource graph, you know exactly
    what Terraform will change and in what
    order, avoiding many possible human
    errors.

tag
    When you have many resources (for example,
    instances, VCNs, load balancers, and block
    volumes) across multiple compartments in
    your tenancy, it can become difficult to
    track resources used for specific
    purposes, or to aggregate them, report on
    them, or take bulk actions on them.

    Tagging allows you to define keys and
    values and associate them with resources.

    You can then use the tags to help you
    organize and list resources based on your
    business needs.

    See Tagging Overview to familiarize
    yourself with concept of tagging and
    features available.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# clone the repository if needed
gc https://github.com/hashicorp/terraform.git

# Verify that the unit tests are passing
make test

# Run preparation steps and then build the executable for each target platform
# in the subdirectory "pkg".
# This generates binaries for each platform and places them in the pkg folder
make bin

   1
   2
   3
   4
   5
   6
   7
   8
   9
  10
  11
  12
  13
  14
  15
  16
  17
  18
  19
  20
  21
  22
  23
  24
  25
  26
  27
  28
  29
  30
  31
  32
  33
  34
  35
  36
  37
  38
  39
  40
  41
  42
  43
  44
  45
  46
  47
  48
  49
  50
  51
  52
  53
  54
  55
  56
  57
  58
  59
  60
  61
  62
  63
  64
  65
  66
  67
  68
  69
  70
  71
  72
  73
  74
  75
  76
  77
  78
  79
  80
  81
  82
  83
  84
  85
  86
  87
  88
  89
  90
  91
  92
  93
  94
  95
  96
  97
  98
  99
 100
 101
 102
 103
 104
 105
 106
 107
 108
 109
 110
 111
 112
 113
 114
 115
 116
 117
 118
 119
 120
 121
 122
 123
 124
 125
 126
 127
 128
 129
 130
 131
 132
 133
 134
 135
 136
 137
 138
 139
 140
 141
 142
 143
 144
 145
 146
 147
 148
 149
 150
 151
 152
 153
 154
 155
 156
 157
 158
 159
 160
 161
 162
 163
 164
 165
 166
 167
 168
 169
 170
 171
 172
 173
 174
 175
 176
 177
 178
 179
 180
 181
 182
 183
 184
 185
 186
 187
 188
 189
 190
 191
 192
 193
 194
 195
 196
 197
 198
 199
 200
 201
 202
 203
 204
 205
 206
 207
 208
 209
 210
 211
 212
 213
 214
 215
 216
 217
 218
 219
 220
 221
 222
 223
 224
 225
 226
 227
 228
 229
 230
 231
 232
 233
 234
 235
 236
 237
 238
 239
 240
 241
 242
 243
 244
 245
 246
 247
 248
 249
 250
 251
 252
 253
 254
 255
 256
 257
 258
 259
 260
 261
 262
 263
 264
 265
 266
 267
 268
 269
 270
 271
 272
 273
 274
 275
 276
 277
 278
 279
 280
 281
 282
 283
 284
 285
 286
 287
 288
 289
 290
 291
 292
 293
 294
 295
 296
 297
 298
 299
 300
 301
 302
 303
 304
 305
 306
 307
 308
 309
 310
 311
 312
 313
 314
 315
 316
 317
 318
 319
 320
 321
 322
 323
 324
 325
 326
 327
 328
 329
 330
 331
 332
 333
 334
 335
 336
 337
 338
 339
 340
 341
 342
 343
 344
 345
 346
 347
 348
 349
 350
 351
 352
 353
 354
 355
 356
 357
 358
 359
 360
 361
 362
 363
 364
 365
 366
 367
 368
 369
 370
 371
 372
 373
 374
 375
 376
 377
 378
 379
 380
 381
 382
 383
 384
 385
 386
 387
 388
 389
 390
 391
 392
 393
 394
 395
 396
 397
 398
 399
 400
 401
 402
 403
 404
 405
 406
 407
 408
 409
 410
 411
 412
 413
 414
 415
 416
 417
 418
 419
 420
 421
 422
 423
 424
 425
 426
 427
 428
 429
 430
 431
 432
 433
 434
 435
 436
 437
 438
 439
 440
 441
 442
 443
 444
 445
 446
 447
 448
 449
 450
 451
 452
 453
 454
 455
 456
 457
 458
 459
 460
 461
 462
 463
 464
 465
 466
 467
 468
 469
 470
 471
 472
 473
 474
 475
 476
 477
 478
 479
 480
 481
 482
 483
 484
 485
 486
 487
 488
 489
 490
 491
 492
 493
 494
 495
 496
 497
 498
 499
 500
 501
 502
 503
 504
 505
 506
 507
 508
 509
 510
 511
 512
 513
 514
 515
 516
 517
 518
 519
 520
 521
 522
 523
 524
 525
 526
 527
 528
 529
 530
 531
 532
 533
 534
 535
 536
 537
 538
 539
 540
 541
 542
 543
 544
 545
 546
 547
 548
 549
 550
 551
 552
 553
 554
 555
 556
 557
 558
 559
 560
 561
 562
 563
 564
 565
 566
 567
 568
 569
 570
 571
 572
 573
 574
 575
 576
 577
 578
 579
 580
 581
 582
 583
 584
 585
 586
 587
 588
 589
 590
 591
 592
 593
 594
 595
 596
 597
 598
 599
 600
 601
 602
 603
 604
 605
 606
 607
 608
 609
 610
 611
 612
 613
 614
 615
 616
 617
 618
 619
 620
 621
 622
 623
 624
 625
 626
 627
 628
 629
 630
 631
 632
 633
 634
 635
 636
 637
 638
 639
 640
 641
 642
 643
 644
 645
 646
 647
 648
 649
 650
 651
 652
 653
 654
 655
 656
 657
 658
 659
 660
 661
 662
 663
 664
 665
 666
 667
 668
 669
 670
 671
 672
 673
 674
 675
 676
 677
 678
 679
 680
 681
 682
 683
 684
 685
 686
 687
 688
 689
 690
 691
 692
 693
 694
 695
 696
 697
 698
 699
 700
 701
 702
 703
 704
 705
 706
 707
 708
 709
 710
 711
 712
 713
 714
 715
 716
 717
 718
 719
 720
 721
 722
 723
 724
 725
 726
 727
 728
 729
 730
 731
 732
 733
 734
 735
 736
 737
 738
 739
 740
 741
 742
 743
 744
 745
 746
 747
 748
 749
 750
 751
 752
 753
 754
 755
 756
 757
 758
 759
 760
 761
 762
 763
 764
 765
 766
 767
 768
 769
 770
 771
 772
 773
 774
 775
 776
 777
 778
 779
 780
 781
 782
 783
 784
 785
 786
 787
 788
 789
 790
 791
 792
 793
 794
 795
 796
 797
 798
 799
 800
 801
 802
 803
 804
 805
 806
 807
 808
 809
 810
 811
 812
 813
 814
 815
 816
 817
 818
 819
 820
 821
 822
 823
 824
 825
 826
 827
 828
 829
 830
 831
 832
 833
 834
 835
 836
 837
 838
 839
 840
 841
 842
 843
 844
 845
 846
 847
 848
 849
 850
 851
 852
 853
 854
 855
 856
 857
 858
 859
 860
 861
 862
 863
 864
 865
 866
 867
 868
 869
 870
 871
 872
 873
 874
 875
 876
 877
 878
 879
 880
 881
 882
 883
 884
 885
 886
 887
 888
 889
 890
 891
 892
 893
 894
 895
 896
 897
 898
 899
 900
 901
 902
 903
 904
 905
 906
 907
 908
 909
 910
 911
 912
 913
 914
 915
 916
 917
 918
 919
 920
 921
 922
 923
 924
 925
 926
 927
 928
 929
 930
 931
 932
 933
 934
 935
 936
 937
 938
 939
 940
 941
 942
 943
 944
 945
 946
 947
 948
 949
 950
 951
 952
 953
 954
 955
 956
 957
 958
 959
 960
 961
 962
 963
 964
 965
 966
 967
 968
 969
 970
 971
 972
 973
 974
 975
 976
 977
 978
 979
 980
 981
 982
 983
 984
 985
 986
 987
 988
 989
 990
 991
 992
 993
 994
 995
 996
 997
 998
 999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390

API
Application Programming Interface
    Any interface designed to allow
    programatic manipulation of some kind of
    software system.

    For most software developers today, the
    most common kinds of APIs are based on
    HTTP requests.

    Terraform relies on cloud service provider
    APIs to manage resources; each service's
    Terraform provider is responsible for
    mapping Terraform's resource model to the
    series of actual API calls necessary to
    create, check, modify, or delete a real
    infrastructure resource in that cloud
    service.

    Terraform Cloud also offers its own API,
    for managing resources like team
    membership, policies, and workspaces. That
    API, in turn, is used by the tfe Terraform
    provider, so you can use Terraform to
    manage the system that runs Terraform for
    you.

    Terraform Cloud docs:
    - API
    Terraform providers:
    - tfe

Apply (noun)
    One of the stages of a run, in which
    changes are made to real infrastructure
    resources in order to make them match
    their desired state.

    The counterpart of a _plan_.

    In Terraform's CLI, applies are performed
    with the terraform apply command.

    Terraform Cloud runs =terraform apply= using
    a plan file as its input.

    Terraform docs:
    - The terraform apply command
    Terraform Cloud docs:
   -  About Runs

Apply (verb)
    To make changes to real infrastructure in
    order to make it match the desired state
    (as specified by a Terraform config and
    set of variables).

    In conversation, it's common to refer to
    "applying a plan" (usually in the context
    of Terraform Cloud's workflow) or
    "applying a configuration" (usually in the
    context of the Terraform CLI workflow).

    Terraform docs:
    - The terraform apply command
    Terraform Cloud docs:
    - About Runs

Argument
    [#Terraform's configuration language]

    A syntax construct that assigns a value to
    a name.

    Arguments have the form
        <IDENTIFIER> = <EXPRESSION>
    and they appear within blocks.

    Most of a Terraform configuration consists
    of using arguments to configure Terraform
    resources.

    Each resource type defines the arguments
    its resources can use, the allowed values
    for each argument, and which arguments are
    required or optional.

    Information about a given resource type
    can be found in the docs for that
    resource's provider.

    Terraform docs:
    - Config Language — Arguments, Blocks and
      Expressions

Attribute
    [#Terraform's configuration language]

    A named piece of data that belongs to some
    kind of object.

    The value of an attribute can be
    referenced in expressions using a dot-
    separated notation, like
    aws_instance.example.id.

    Terraform resources and data sources make
    all of their arguments available as
    readable attributes, and also typically
    export additional read-only attributes.

    Terraform docs:
    - Expressions — Indices and Attributes

Backend
    The part of Terraform's core that
    determines how Terraform stores state and
    performs operations (like plan, apply,
    import, etc.).

    Terraform has multiple backends to choose
    from, which can be configured in a variety
    of ways.

    Backends are not plugins, so it is not
    possible to install additional backends.

    In a general CS sense, a backend is any
    lower-level implementation that enables a
    higher-level feature.

    But in the context of Terraform, "backend"
    always means the built-in code that
    handles state and operations.

    Terraform docs:
    - Backends

Blob Storage
    [#Terraform Cloud]

    An API service for storing and retrieving
    arbitrary chunks of data using opaque
    addresses, which are indexed by a
    directory of some kind. The most notable
    example is AWS's S3.

    You do not need to be familiar with the
    properties and advantages of blob storage
    services in order to work with Terraform
    or Terraform Cloud. However, you might
    need to administer or configure a blob
    storage service if you are responsible for
    administering a Terraform Enterprise
    instance.

Block
    In Terraform's configuration language: a
    container for other content which usually
    represents the configuration of some kind
    of object, like a resource. Blocks have a
    block type, can have zero or more labels,
    and have a body that contains any number
    of arguments and nested blocks. Most of
    Terraform's features are controlled by
    top-level blocks in a configuration file.

        resource "aws_vpc" "main" {
          cidr_block = var.base_cidr_block
        }

        <BLOCK TYPE> "<BLOCK LABEL>" "<BLOCK LABEL>" {
          # Block body
          <IDENTIFIER> = <EXPRESSION> # Argument
        }

    Terraform docs:
    - Config Language — Arguments, Blocks and Expressions

Branch
    In some version control systems: a
    semi-independent history of changes to
    content in a repository. A branch
    generally shares some history with other
    branches in the same repository, but
    eventually diverges to include changes
    that aren't yet present elsewhere.

    A repository usually has a default branch
    (whose name, in Git, defaults to master),
    which successful changes are eventually
    merged into. Most modern development
    workflows also include topic branches
    (where a specific set of changes is
    explored, iterated on, and verified), and
    some workflows include long-lived branches
    other than the default branch.

CLI
Command-line interface.
    The terraform command expects to be run in
    a CLI (a Unix shell or the Windows command
    prompt), which it uses to accept
    instructions and return text output.

    We often use "Terraform CLI" to refer to
    the core open source Terraform binary when
    we need to distinguish it from other parts
    of the Terraform ecosystem (like Terraform
    Cloud or the Terraform GitHub Actions).

    Terraform docs:
    - Commands (CLI)

Commit
    In a version control system: A coherent
    set of changes saved to a repository's
    version history.

    In Git, commits act like a complete
    snapshot of the contents of a repo, on a
    specific branch (or group of branches with
    shared history) and at a specific moment
    in time.

    Each commit also records the identity of
    its parent(s), which enables viewing the
    entire history of the repo up to any
    specific moment.

    Additionally, comparing a commit to its
    parent(s) can reveal the exact changes
    introduced by that commit; if those
    changes are applied as a diff, they can be
    added to a different branch in the repo
    without merging in the entire history of
    the commit in question.

Configuration
config
    [#terraform]

    Code written in Terraform's configuration
    language that declaratively describes the
    desired state of your infrastructure.

    A complete config consists of a root
    module, which can optionally call any
    number of child modules.

    Terraform docs: Configuration Language

Configuration Version
    [#Terraform Cloud]

    Also "config version".

    The contents of a Terraform config at a
    specific moment in time.

    This concept only applies to Terraform
    Cloud, since the Terraform CLI doesn't
    have visibility into repeated runs for a
    specific configuration over a period of
    time.

    Every stage of a given run uses one
    specific configuration version.

    Config versions can be automatically
    imported when new commits are merged to a
    workspace's repo, uploaded via the API, or
    uploaded by running terraform plan or
    terraform apply as a remote operation.

    Adding a new config version is sometimes
    called "ingressing."

Cost Estimation
    [#Terraform Cloud]

    Part of a run.

    After gathering the plan file for a run,
    Terraform Cloud uses plan data to estimate
    costs for each resource found in the plan.

    Previous and proposed resources are given
    estimated costs, providing an estimated
    delta cost between the two.

    The results can be used in Sentinel
    policies.

    Terraform Cloud docs:
    - Run States and Stages

Data Source
    A resource-like object that can be
    configured in Terraform's configuration
    language.

    Unlike resources, data sources do not
    create or manage infrastructure. Instead,
    they return information about some kind of
    external object in the form of readable
    attributes. This allows a Terraform
    configuration to make use of information
    defined outside of Terraform, or defined
    by another separate Terraform
    configuration.

    Data sources are implemented by providers.

    Terraform docs:
    - Data Sources

Deposed
    This status tracks a resource that was
    marked for deletion, but still remains in
    the Terraform state and infrastructure due
    an error from a previous apply.

    Terraform expected to replace the existing
    resource by creating a new resource, then
    destroying the existing resource, but an
    error occurred in the apply before the
    destruction.

    Existing references to the resource refer
    to the new resource.

    Terraform will destroy the deposed
    resource on the next apply.

    This only can occur in resource
    configurations that have the lifecycle
    configuration block create_before_destroy
    argument set to true.

    Terraform docs:
    - Resources

Expression
    [#Terraform's configuration language]

    A piece of syntax that represents a value,
    either literally or by referencing and
    combining other values. Expressions appear
    as values for arguments, or within other
    expressions.

    Prior to Terraform 0.12, [interpolation][]
    was the only way to use non-literal
    expressions in Terraform configurations;
    in 0.12 and later, expressions can be used
    independently.

    Terraform docs:
    - Expressions

Fork
forked repository
forked repo
    A VCS repository that was created by
    copying content and history from another
    repository.

    Different VCS providers handle forks
    differently, but a fork is usually owned
    by a different person or organization than
    the original repo, and a fork usually does
    not inherit all of the original repo's
    access permissions.

    Terraform Cloud makes extensive use of VCS
    repos, and assumes that forks of a trusted
    repo are not necessarily trusted.

    As such, Terraform Cloud avoids evaluating
    any code from external forks, which
    prevents Terraform Cloud from running
    speculative plans for pull requests from
    forks.

Git
    A distributed version control system for
    tracking changes in source code during
    software development.

    It is designed for coordinating work among
    programmers, but it can be used to track
    changes in any set of files.

HCL
    HashiCorp Configuration Language.

    The structured configuration syntax that
    serves as the basis for Terraform's
    configuration language, as well as the
    configuration layer for several other
    HashiCorp products.

    HCL establishes the syntax Terraform uses
    for things like arguments, blocks, literal
    values, and expressions.

    But what most people think of as the
    Terraform language extends beyond just the
    syntax; the built-in functions, Terraform-
    specific block types (like resource and
    variable), and Terraform-specific named
    values available in expressions are all
    implementation details of Terraform
    itself.

    Terraform docs: Configuration Language

ID
    An identifier; an opaque string
    permanently associated with a specific
    object, which doesn't contain any
    information about the object but which can
    be used to retrieve information about it
    or perform actions on it via an API.

    In Terraform, many resource types have an
    ID attribute that helps link Terraform's
    state to the real infrastructure resource
    being managed.

    In Terraform Cloud, most internal
    application objects (like workspaces,
    users, policies, etc.) can be identified
    by both a name and by an opaque, permanent
    ID. Most API endpoints use IDs instead of
    names, since names sometimes change. IDs
    for Terraform Cloud's application objects
    are sometimes called "external IDs."

    You can usually copy an external ID from
    the URL bar when viewing an object in
    Terraform Cloud's UI. Workspaces don't
    display an ID in the URL bar, but their
    general settings page includes a UI
    control for viewing and copying the ID.

Ingress
    Terraform Cloud

    The process of bringing content into
    Terraform Cloud. Usually that content is a
    configuration version, but it can also be
    a private module version or some other
    kind of content.

    This term comes from Terraform Cloud's
    internal subsystems. Most documentation
    and UI avoids using "ingress," but it can
    sometimes appear in API contexts or
    support conversations.

Input Variables
    See Variables.

Interpolation
    Using a special placeholder to insert a
    computed value into a string.

    Terraform's configuration language
    supports interpolation in strings using
        ${<EXPRESSION>}
    placeholders. For example:

    "Hello, ${var.name}!"

    Prior to Terraform 0.12, interpolation was
    the only way to use non-literal
    expressions in Terraform configurations;
    in 0.12 and later, expressions can be used
    independently.

    Interpolation is a very common feature in
    programming languages; for example, Ruby
    uses #{<EXPRESSION>} placeholders in
    double-quoted strings, and JavaScript (ES6
    and up) uses ${<EXPRESSION>} placeholders
    in backtick-quoted strings.

    Terraform docs:
    - Expressions - String Templates

JSON
    "JavaScript Object Notation". A popular
    text-based data interchange format, which
    can represent strings, numbers, booleans,
    null, arrays, and objects/maps.

    Terraform and Terraform Cloud often
    interact with JSON data in order to
    consume or provide APIs. Terraform also
    supports JSON as an alternate format for
    configurations.

    Terraform docs:
    - JSON Configuration Syntax

Locking
    Terraform Cloud

    The ability to prevent new runs from
    starting in a given workspace. Workspaces
    are automatically locked while a run is in
    progress, and can also be manually locked.

    The remote backend respects the lock
    status in Terraform Cloud workspaces. Some
    other Terraform backends can also lock
    state during runs.

Log
    The text-based output of actions taken
    within a run. For example, the output of
    running terraform plan.

Module
    Also "Terraform module".

    A self-contained collection of Terraform
    configurations that manages a collection
    of related infrastructure resources.

    Other Terraform configurations can call a
    module, which tells Terraform to manage
    any resources described by that module.

    Modules define input variables (which the
    calling module can set values for) and
    output values (which the calling module
    can reference in expressions).

    Terraform docs: Modules

OAuth
    An open standard for token-based
    authorization between applications on the
    internet.

    Terraform Cloud uses OAuth to connect your
    organization to your VCS provider.
    Generally takes an id and secret from your
    VCS provider to give access to Terraform
    Cloud and allow it to pull in
    configuration from the provider.

    Terraform Cloud docs: VCS Integration

OAuth Client
    Terraform Cloud

    An entity collecting the configuration
    information that a Terraform Cloud
    organization needs in order to connect to
    a specific VCS provider.

    An OAuth client needs an OAuth token in
    order to actually access data belonging to
    a user or organization in that VCS
    provider. The client can be created with
    an existing token for that VCS provider
    (API-only, and not supported for some VCS
    providers), or it can be created with the
    details Terraform Cloud needs in order to
    request a token. Requesting a token
    requires a user to click through and
    approve access with their VCS provider
    account.

    Terraform Cloud docs:
    - VCS Integration
    Terraform Cloud API docs:
    - OAuth Clients

OAuth Token
    Terraform Cloud

    In general: A secret string that allows an
    application to authenticate itself to
    another application. The token is
    generated ahead of time by the application
    being accessed (either during the OAuth
    authorization exchange or in response to a
    direct request by a user), and allows
    access with whatever permissions that
    application assigns to the token. The VCS
    providers supported by Terraform Cloud
    allow access via OAuth tokens; that access
    is generally restricted to data belonging
    to a given user or organization within
    that provider.

    Within Terraform Cloud: An entity in the
    Terraform Cloud application that
    associates an OAuth token (in the "secret
    string" sense) with a permanent ID and
    with metadata about which VCS provider it
    applies to and which VCS user approved the
    token. When documentation refers
    specifically to this kind of entity, the
    name is often styled as oauth-token to
    indicate that it's an entity you can
    interact with via the API.

    An oauth-token has a one-to-one
    relationship with an OAuth client, but the
    client can outlive a specific token, to
    allow revoking and re-requesting VCS
    access.

    Workspaces that are linked to a VCS repo
    have a relationship with one oauth-token.

    Terraform Cloud docs:
    - VCS Integration

    Terraform Cloud API docs:
    - OAuth Tokens

Organization
    Terraform Cloud

    Terraform Cloud's fundamental unit for
    controlling access and grouping things
    together; meant to represent a company or
    a business unit within a company. An
    organization contains a group of
    workspaces, a group of teams, a group of
    Sentinel policies, and a variety of
    settings. Adding users to an organization
    is done via teams.

    Terraform Cloud docs:
    - Organizations

Output Values
    Also "outputs".

    Data exported by a Terraform module, which
    can be displayed to a user and/or
    programmatically used by other Terraform
    code.

OSS
    "Open-Source Software". Terraform and the
    publicly available Terraform providers are
    open-source. Terraform Cloud and Terraform
    Enterprise are closed-source commercial
    software, but they make use of Terraform
    and the available Terraform providers.

    Wikipedia: Open-Source Software

Permissions
    Terraform Cloud

    Specific levels of access allowed within
    Terraform Cloud. Can be managed at the
    workspace and/or organization level. For
    example, a user with "read" permissions
    for a workspace can see a list of runs but
    cannot approve a run like a user with
    "write" permissions can.

    Terraform Cloud docs: Permissions

Plan (verb)
    Also "queue plan".

    To start a new run, which begins by
    running a Terraform plan (noun).

    Terraform Cloud docs: About Runs

Plan (noun, 1)
    One of the stages of a run, in which
    Terraform compares the managed
    infrastructure's real state to the
    configuration and variables, determines
    which changes are necessary to make the
    real state match the desired state, and
    presents a human-readable summary to the
    user. The counterpart of an apply.

    In Terraform's CLI, plans are performed by
    all of the following commands:

    terraform plan
        which only performs a plan. It can
        optionally output a plan file, which
        terraform apply can use to perform
        that exact set of planned changes.
    terraform apply
        which performs a plan and then, if a
        user approves, immediately applies it.
    terraform destroy
        which is similar to terraform apply
        but uses a desired state in which none
        of the managed resources exist; if the
        plan is approved, those resources are
        destroyed.

    In Terraform Cloud, plans are performed by
    committing changes to a workspace's
    configuration, running terraform plan or
    terraform apply with the remote backend
    enabled, manually queueing a plan, or
    uploading a configuration via the API.

    Terraform Cloud's workflow always creates
    a plan file, which can be auto-applied or
    can wait for a user's approval. Terraform
    Cloud also supports speculative plans,
    which are for informational purposes only
    and cannot be applied.

    Terraform docs:
    - The terraform plan command
    Terraform Cloud docs:
    - About Runs

Plan File
    Also ".tfplan", "saved plan", or simply
    "plan" in contexts where it's clearly
    referring to an artifact.

    A binary artifact optionally produced by
    the terraform plan command, which
    terraform apply can use to carry out the
    exact changes that were decided at the
    time of the plan.

    Terraform Cloud always uses a saved plan
    as the input to an apply, so that applies
    never make changes that weren't shown to
    the user after the plan (in cases where
    the config or the variables changed in the
    meantime).

Policy
    Terraform Cloud

    Sentinel code that can be enforced on
    runs. Combined into policy sets.

    Terraform Cloud docs: Managing Sentinel Policies

Policy Check
    Terraform Cloud

    Part of a run. After gathering the
    configuration, state, and plan file for a
    run, Terraform Cloud runs Sentinel to
    check that data against the active
    policies. Policy checks end in success or
    failure. If a failure occurs in a required
    policy, this can prevent the run from
    proceeding to the apply stage.

    Terraform Cloud docs: Run States and Stages

Policy Set
    Terraform Cloud

    A list of Sentinel policies to enforce
    globally or on specific workspaces.

    Terraform Cloud docs: Managing Sentinel
    Policies

Private Module Registry
    Terraform Cloud

    Also "private Terraform registry".

    A version of the Terraform Registry that
    is built-in to Terraform Cloud, to enable
    code sharing within an organization. It
    includes a configuration designer, which
    lets you combine and configure modules to
    generate a Terraform configuration that
    uses them.

    Terraform Cloud docs: Private Registry

Private Terraform Enterprise (PTFE)
    Terraform Enterprise.

    Prior to mid-2019, "Terraform Enterprise"
    (TFE) was the name of the Terraform Cloud
    application, and "Private Terraform
    Enterprise" (PTFE) was the name of the
    on-premises distribution.

    Terraform Enterprise docs

(Terraform) Provider
    A plugin for Terraform that makes a
    collection of related resources available.
    A provider plugin is responsible for
    understanding API interactions with some
    kind of service and exposing resources
    based on that API.

    Terraform providers are generally tied to
    a specific infrastructure provider, which
    might be an infrastructure as a service
    (IaaS) provider (like AWS, GCP, Microsoft
    Azure, OpenStack), a platform as a service
    (PaaS) provider (like Heroku), or a
    software as a service (SaaS) provider
    (like Terraform Cloud, DNSimple,
    Cloudflare).

    There are many existing providers
    available, but providers can also be
    custom-built to work with any API.

    Terraform docs: Providers

Pull Request (PR)
    A mechanism created by GitHub to review
    and discuss changes made to a Git
    repository branch that a user wants to
    merge into another branch. Other
    collaborators can request changes,
    approve, or reject these changes.

    Conversationally, people often say "pull
    request" to refer to this
    review-before-merging workflow even when
    working with a VCS provider that calls it
    something else. (For example, GitLab calls
    this a Merge Request.)

Queue
    Terraform Cloud

    The list of runs waiting to be processed.
    Terraform Cloud uses several queues of
    runs, including a per-workspace queue
    (since only one run at a time is allowed
    in a given workspace, to avoid conflicts
    and state corruption) and a global
    per-instance queue (since compute
    resources are finite and Terraform Cloud
    only has access to so many VMs).

(Terraform) Registry
    A repository of modules written by the
    Terraform community, which can be used
    as-is within a Terraform configuration or
    forked and modified. The registry can help
    you get started with Terraform more
    quickly, see examples of how Terraform is
    written, and find pre-made modules for
    infrastructure components you require.

    Terraform docs: The Terraform Registry

Remote Operations
    Terraform Cloud

    The ability to start a run (or perform a
    few other tasks) from your local CLI and
    view output inline, while still allowing
    Terraform Cloud to perform the actual
    operation.

    Terraform Cloud performs Terraform runs in
    its own disposable VMs, where it can
    capture information, control access to
    secrets, etc., but many users are
    accustomed to running Terraform on their
    local machines. Remote operations exist to
    help split the difference.

    Terraform docs: Remote Operations

Remote Backend
    A Terraform CLI feature that lets
    Terraform connect to Terraform Cloud, by
    specifying in the Terraform configuration
    which organization and workspace(s) to
    use. Used for remote operations in
    Terraform Cloud workspaces, and used for
    state storage in Terraform Cloud's free
    tier.

    See also backend. Older documentation
    sometimes refers to backends like s3 or
    consul as "remote backends," since they
    store Terraform's state in a remote
    service instead of the local filesystem,
    but today this term usually means the
    specific backend whose name is remote.

    Terraform docs: The remote Backend

Repository
    Also "repo".

    A collection of files and a history of the
    changes to them, managed by a version
    control system. In Terraform Cloud, a
    "repo" is generally a Git repository that
    contains a Terraform configuration,
    although private modules are also based on
    Git repos.

    Wikipedia: Repository (version control)

Resource
    Also "infrastructure resource".

    In Terraform's configuration language: A
    block that describes one or more
    infrastructure objects. Resources can be
    things like virtual networks, compute
    instances, or higher-level components such
    as DNS records.

    In other Terraform-related contexts: An
    infrastructure object of a type that could
    be managed by Terraform.

    A resource block in a configuration
    instructs Terraform to manage the
    described resource — during a run,
    Terraform will create a matching real
    infrastructure object if one doesn't
    already exist, and will modify the
    existing object if it doesn't match the
    desired configuration. Terraform uses
    state to keep track of which real
    infrastructure objects correspond to
    resources in a configuration.

    Terraform uses cloud provider APIs to
    create, edit, and destroy resources.
    Terraform providers are responsible for
    defining resource types and mapping
    transitions in a resource's state to a
    specific series of API calls that will
    carry out the necessary changes.

    Terraform docs: Resources

Root Module
    The place where Terraform begins
    evaluating a configuration. The root
    module consists of all of the
    configuration files in Terraform's working
    directory.

    The root module's variables and outputs
    are handled directly by Terraform (unlike
    child modules, whose variables and outputs
    are handled by the calling module). Root
    variable values can be provided with
    Terraform Cloud, .tfvars files, CLI
    options, or environment variables. Root
    outputs are printed after a run and stored
    in the state.

Root Outputs
    Also "root-level outputs".

    The output values of a configuration's
    root module. A configuration can access
    the root outputs of another configuration
    with a terraform_remote_state data source.

Run
    Also "Terraform Run".

    The process of using Terraform to make
    real infrastructure match the desired
    state (as specified by the contents of the
    config and variables at a specific moment
    in time).

    In Terraform Cloud, runs are performed in
    a series of stages (plan, policy check,
    and apply), though not every stage occurs
    in every run. Terraform Cloud saves
    information about historical runs.

    Learn Terraform: Getting Started
    Terraform Cloud docs: About Runs
S3
    Amazon Web Services' "Simple Storage
    Service", a service for storing and
    retrieving arbitrary blobs of data.

    Many other cloud or self-hosted services
    provide APIs that are compatible with S3's
    API, which allows them to be used with
    software that was designed to work with
    S3.

    Terraform's aws provider can manage S3
    resources.

    Terraform Enterprise can use an
    S3-compatible blob storage service when
    configured to use External Services for
    storage.

    AWS: S3

SAML
    Terraform Enterprise

    SAML is an XML-based standard for
    authentication and authorization.
    Terraform Enterprise can act as a service
    provider (SP) (or Relying Party, RP) with
    your internal SAML identity provider
    (IdP). The SAML Single Sign On feature is
    only available on Terraform Enterprise;
    the Terraform Cloud SaaS does not support
    it.

    Terraform Enterprise docs: SAML Single Sign-On

Sentinel
    Terraform Cloud

    A language and runtime for managing policy
    as code. Allows you to define rules around
    operations in Terraform Cloud.

    Terraform Cloud docs: Sentinel

Site Admin
    Terraform Enterprise

    An administrator of a Terraform Enterprise
    instance, who has access to application
    settings that affect all organizations
    using the instance.

    Terraform Enterprise docs: Administration

Speculative Plan
    Terraform Cloud

    A run that is only intended to show
    possible changes to infrastructure, when
    using a given config version and set of
    variables. Speculative plans can never be
    applied, and are usually started as a
    result of pull requests to a workspace's
    repo, or by running terraform plan on the
    command line with remote operations
    configured.

SSH Key
    A type of access credential based on
    public key cryptography, used to log into
    servers.

    Terraform Cloud uses SSH private keys for
    two kinds of operations:

    Downloading private Terraform modules with
    Git-based sources during a Terraform run.
    Keys for downloading modules are assigned
    per-workspace.

    Bringing content from a connected VCS
    provider into Terraform Cloud, usually
    when pulling in a Terraform configuration
    for a workspace or importing a module into
    the private module registry. Only some VCS
    providers require an SSH key, but others
    can optionally use SSH if an SSH key is
    provided.

    Wikipedia: SSH

    Terraform Cloud docs: SSH Keys for Cloning
    Modules

State
    Terraform's cached information about your
    managed infrastructure and configuration.
    This state is used to persistently map the
    same real world resources to your
    configuration from run-to-run, keep track
    of metadata, and improve performance for
    large infrastructures.

    Without state, Terraform has no way to
    identify the real resources it created
    during previous runs. Thus, when multiple
    people are collaborating on shared
    infrastructure, it's important to store
    state in a shared location, like a free
    Terraform Cloud organization.

    Terraform docs: State

State Version
    Terraform Cloud

    A snapshot of your infrastructure's state
    at a point in time. Can be manually
    uploaded to Terraform Cloud or created as
    the result of an apply.

    Terraform CLI doesn't have any concept of
    historical state data; it only interacts
    with the most recent state, and writes a
    snapshot of the new state to the
    configured backend after making changes.
    Whatever system that backend writes to can
    choose to retain previous state; Terraform
    Cloud does this, and some other backends
    (like S3) can also be configured to keep
    historical snapshots. The local backend
    does not.

Team
    Terraform Cloud

    A group of Terraform Cloud users, which
    can be given permission to access and/or
    edit various objects (workspaces,
    policies, etc.) within an organization. A
    team belongs to a single organization.
    Users can belong to any number of teams in
    any number of organizations.

    Terraform Cloud docs: Teams

Terraform
    A tool for building, changing, and
    versioning infrastructure safely and
    efficiently. Terraform can manage existing
    and popular service providers as well as
    custom in-house solutions.

    Intro to Terraform

Terraform Cloud
    An application that helps teams use
    Terraform together. Terraform Cloud
    provides a consistent environment for
    Terraform runs, as well as hosting
    Terraform state and other shared
    information.

    Terraform Cloud is available as a hosted
    service at https://app.terraform.io. It is
    also available in an on-premises
    distribution called Terraform Enterprise.

    Prior to mid-2019, "Terraform Enterprise"
    (TFE) was the name of the Terraform Cloud
    application, and "Private Terraform
    Enterprise" (PTFE) was the name of the
    on-premises distribution.

    Terraform Cloud docs

Terraform Enterprise
    An on-premises distribution of Terraform
    Cloud, which enables large enterprises to
    host their own private instance of the
    application.

    Prior to mid-2019, "Terraform Enterprise"
    (TFE) was the name of the Terraform Cloud
    application, and "Private Terraform
    Enterprise" (PTFE) was the name of the
    on-premises distribution.

    Terraform Enterprise docs

Terraform Version
    Terraform Cloud

    A particular version of the terraform
    binary available for use in Terraform
    Cloud workspaces. Specifies a URL, a
    SHA256 checksum and enabled/beta flags.

    Site admins can configure the available
    Terraform versions for a Terraform
    Enterprise instance.

    Terraform Enterprise docs: Managing
    Terraform Versions
TFE
    Terraform Enterprise.

    Terraform Enterprise docs

TFE Provider / Terraform Cloud Provider
    A Terraform provider that manages
    Terraform Cloud. Allows you to manage
    Terraform Cloud using a Terraform
    configuration.

    Provider docs: tfe

(API) Token
    Terraform Cloud

    A revocable secret string that
    authenticates a user, to allow use of
    Terraform Cloud's API or the remote
    backend.

    Different kinds of tokens grant different
    permissions. Tokens can be granted by
    user, team, or organization.

    Many applications other than Terraform
    Cloud use token-based authentication, but
    within Terraform Cloud's documentation and
    UI, "token" without any other
    qualification generally means a Terraform
    Cloud API token.

    Terraform Cloud docs: User Tokens
    Terraform Cloud docs: Team Tokens
    Terraform Cloud docs: Organization Tokens

Trigger
    Terraform Cloud

    Something that causes a new run to queue.
    Runs can be UI/VCS-driven (in which case
    the trigger is a new VCS commit or a UI
    action), API-driven (in which case the
    trigger is an API call) or CLI-driven (in
    which case the trigger is a CLI command).

    Terraform Cloud docs: UI/VCS-based Run
    Workflow

Variables
    Also "input variables".

    In general-purpose programming, a variable
    is a symbolic name associated with a
    value.

    In Terraform, "variables" almost always
    refers to input variables, which are
    key/value pairs used in a run. Terraform
    modules can declare variables to allow
    customization. For child modules, the
    parent module provides a value when
    calling the module; for the root module,
    values are provided at run time.

    Terraform Cloud lets you set values for
    root input variables in a workspace, so
    all collaborators can use the same values.
    Variable values marked as "sensitive"
    become unreadable in the UI and API, and
    all variable values are protected by
    Vault.

    Terraform docs: Input Variables
    Terraform Cloud docs: Variables

VCS
    Version Control System, like Git. Software
    that tracks changes over time to a
    collection of files, making it possible to
    keep track of changes, undo changes, and
    combine changes made in parallel by
    different users. Usually used for any
    non-trivial code effort, including
    infrastructure as code.

    Different VCSes use different models for
    history; Git models changes as a directed
    acyclic graph of commits, and parallel
    changes that begin from the same parent
    commit become diverging branches (which
    might later be merged together).

    Wikipedia: Version Control

VCS Provider
    Terraform Cloud

    A specific service that provides VCS
    features, with the goal of enabling teams
    to collaborate on code. Terraform Cloud
    can integrate with VCS providers to access
    your Terraform configurations and modules,
    and currently supports GitHub, GitHub
    Enterprise, GitLab.com, GitLab EE and CE,
    Bitbucket Cloud, Bitbucket Server, Azure
    DevOps Server, and Azure DevOps Services.

    Terraform Cloud docs: Connecting VCS Providers

Webhook
    A server-to-server HTTP request, in which
    one system responds to a change in its
    internal state by sending information to
    another system.

    The recipient of a webhook might return
    information to the requesting system, call
    other webhooks in response, perform its
    action silently, or ignore the request
    entirely.

    Terraform Cloud uses webhooks in multiple
    ways. Most notably:

    Terraform Cloud creates webhook
    configurations on VCS providers, so that
    they send webhook requests to Terraform
    Cloud whenever linked repositories receive
    pull requests or new commits. (Terraform
    Cloud docs: UI/VCS-driven Runs)

    Users can create webhook configurations on
    Terraform Cloud workspaces, so that
    Terraform Cloud will send run notification
    webhooks to Slack or other external
    services. (Terraform Cloud docs: Run
    Notifications)

Working Directory
    The directory where terraform init runs,
    creating a .terraform subdirectory. All
    subsequent commands for the same
    configuration should then be run from the
    same working directory.

    The root module consists of all of the
    configuration files in the top level of
    Terraform's working directory.
    Subdirectories of the working directory
    can contain child modules.

Workspace
    In Terraform CLI, a workspace is an
    isolated instance of state data. Using
    multiple workspaces lets you manage
    multiple non-overlapping sets of
    infrastructure from a single configuration
    in a single working directory.

    In Terraform Cloud, a workspace is a
    complex object that represents everything
    needed to manage a specific collection of
    infrastructure resources over time. In
    particular, this includes:

    A Terraform configuration (which has
    multiple versions over time, and which can
    come from a repo or from manual uploads)
    A set of variables

    State data that represents the current and
    historical condition of the infrastructure
    Historical information about runs.

    All Terraform Cloud runs occur in the
    context of a workspace — they use that
    workspace's config data, use that
    workspace's state to identify the real
    infrastructure being managed, and edit
    that workspace's state to match any
    infrastructure changes during the run. A
    workspace belongs to an organization.

    Terraform Cloud docs: Workspaces
    Terraform docs: Workspaces