--- shuffleAnswers: true shuffleQuestions: true nQuestions: 25 introduction: >
The test contains a set of questions and there is no time limit. The test is not official, it's just one of the most efficient ways to see how much you know, or don't know, about the subject.

Count your score

You will get 1 point for each correct answer. At the end of the Quiz, your total score will be displayed.

Reflect on you answers

Please conduct a self review of your answers once you complete the quiz test. Being an active participant in your own evaluation, honestly assess your strengths and also areas you need to improve. Good luck!

---

--- # Your team is asked to address the issue that the terraform code is issuing the database password after you issue the 'terraform apply' command. How would you ensure the security of the passwords? 1. [ ] Encrypt the plaintext values to display the output as random values 1. [ ] Password is encrypted in the database 1. [x] Use sensitive Parameter > Make use of a delicate parameter. By running the terraform apply and plan command on the console, the value is not displayed. The password for the state files can be seen in plain-text format if you have access. 1. [ ] Use `terraform plan -var-file= "password=no"` to hide output values > https://www.terraform.io/docs/state/sensitive-data.html # You are a DevOps Engineer working in a CI/CD Pipeline using Jenkins. You have three stages identified: Init, Plan and Apply. After your terraform plan, you need to apply your infrastructur1. [ ] In your pipeline script basically you wrote: "terraform apply”. After triggering the pipeline you see that there was no progress and the Apply stage is waiting to confirm the changes. How can you automatically apply the changes when you type "terraform apply” ? 1. [x] terraform apply -auto-approve 1. [ ] terraform apply -yes 1. [ ] terraform apply | echo "yes” 1. [ ] terraform apply | yes # What is the name of the workspace when you execute "terraform init”? 1. [ ] New 1. [ ] No workspace is created 1. [ ] Workspace 1. [x] Default # Do Terraform workspaces assist in adding/allowing multiple state files for a single configuration? 1. [ ] False 1. [x] True > Terraform workspaces allow configuring multiple state files and associating with a single configuration file > Reference: https://www.terraform.io/docs/state/workspaces.htm # Why should one use provisioners? Please pick the choices from below - [x] Remote-exec helps to run commands remotely on virtual machine - [x] Local-exec is a provisioner which helps to run scripts locally on machine where terraform is installed - [ ] Local-exec is used to run things on remote virtual machines - [ ] File provisioner is a provisioner which is used to run or execute configurable scripts on remote instances > https://www.terraform.io/docs/language/resources/provisioners/file.html > https://www.terraform.io/docs/language/resources/provisioners/localexec.html > https://www.terraform.io/docs/language/resources/provisioners/remote-exec.html # Is it possible to switch between Terraform Workspaces? Can we transition from the 'default workspace' to 'Workspace A' and vice versa, assuming we have both a 'default workspace' and 'Workspace A'? 1. [ ] False 1. [x] True > To switch between workspaces, use the terraform workspace select command. > Reference: https://www.terraform.io/docs/cli/commands/workspace/select.html # What are the benefits of using a private registry in Terraform? Select all that apply. - [ ] Terraform cloud private registry is a paid feature. - [x] Using a private registry, all the modules can be shared within or across organizations. - [x] It supports module versioning, filtered list of available modules, and configuration designer to build new workspaces - [x] It is very similar to the public Terraform Registry. > The private module registry in Terraform Cloud allows you to share Terraform modules across your organisation. It features module versioning, a searchable and filterable list of available modules, and a configuration designer to assist you in quickly creating new workspaces. The private module registry is designed to work similarly to the public Terraform Registry. > https://www.terraform.io/docs/cloud/registry/index.html # You have to configure 10 instances of a resource using single configuration in different environments. What is the best possible and most efficient way to create using terraform? 1. [x] `Workspaces` > Within a single backend, named workspaces make it easy to switch between multiple instances of a single configuration. They are useful in a variety of situations. Using the For Each and Count meta arguments, we can create multiple instances in the same environment. 1. [ ] Using `count` meta argument > Because the question asks for different environments. 1. [ ] Using `For Each` meta argument > Because in the question it's asksed for different environments. 1. [ ] By copying the same code in different environment directories and executing the codes one by one > it can work, but it is not the most effective or efficient method. > For more information: https://www.terraform.io/docs/language/state/workspaces.html # Your colleague made some changes to the `myworkspace` Terraform workspace and wants to check the state file, but can't find it. Select the appropriate option from the list below to save your changes. 1. [ ] .terraform.d 1. [ ] tfstate.var 1. [ ] terraform 1. [x] terraform.tfstate.d > Workspaces are the same as renaming your state file in terms of functionality. They don't get much more complicated than that. Terraform adds a layer of protection and support for the remote state to this simple concept. Terraform stores workspace states in a directory called `terraform.tfstate.d` for local state. > For more information: Please see the following link for more information: https://www.terraform.io/docs/language/state/workspaces.html#workspace-internals # You've recently joined a new company and have been assigned the task of teaching developers the fundamentals of terraforming. What is the workflow that you will recommend to them? 1. [ ] Learn terrafrom, write code and push to git and start deploying the infrastructure 1. [ ] Create a terrafrom state with all the requirements and do `terrafrom apply` every time you deploy 1. [x] Write a code, do `terraform plan` and then `terraform apply` to properly deploy the infrastrucute 2. [ ] Learn as you go, deploy get your hands on terraform # Which of the following is not a native Infrastructure as tool (IaC)? 1. [ ] Cloudformation 2. [ ] Azure Resource Manager 3. [ ] Terraform 4. [x] Puppet > Puppet can also be used for iac purpose, but is is a configuration management tool, which means it is designed to install and manage software on existing servers. > https://www.terraform.io/intro/vs/index.html
> https://aws.amazon.com/cloudformation/
> https://docs.microsoft.com/en-us/azure/azure-resourcemanager/management/overview # An organization has different environment like dev, UAT and prod. They want to use same configuration across all environments with different state files. How can this be efficiently achieved using terraform local backend? 1. [ ] Create an individual folder for each region and place the same configuration. > because keeping a separate folder for each environment is not a good idea. 1. [x] Use the concept of terraform workspace to achieve this. > because we can use same configuration to apply for different environments with different state files. Using workspace concepts, Terraform workspace for local backend can efficiently handle different environments with the same configuration. Terraform stores workspace states in a directory called `terraform.tfstate.d` for local state. This directory should be treated similarly to the `terraform.tfstate` directory, which is only accessible locally. 1. [ ] Create remote repositories and place same configuration file in each repositories. > because it is inefficient to maintain a separate repository for each environment. 1. [ ] Use terraform apply -backup=path to backup the state file for each environment, so that we will have different state files for each region. > because the –backup option will take a backup of the previous state file, but maintaining different environments state files is cumbersome. > For more information: https://www.terraform.io/docs/state/workspaces.html # After deploying an instance, your colleague wants to deploy some configurations. What are the steps he needs to take to install the configurations? 1. [ ] Use terraform remote provisoners to install. 1. [ ] Logon to instance and manually install as it is one time install. 1. [x] Take the data backup, taint/replace the resource, add the provisioner code and create the resource again. > We'll have to recreate the resource as provisioners, which can only run during the create or destroy phases and not in the middle. It is not possible to create a resource with the same name; doing so will result in the resource's destruction. As a result, we must make a backup of the resource and then recreate it. 1. [ ] Create an new instance with bootstrap configurations and clone it. > https://www.terraform.io/docs/cli/state/taint.html > https://www.terraform.io/docs/language/resources/provisioners/syntax.html # Can we map a Terraform Workspace to multiple repositories? True or False. 1. [ ] True 1. [x] False > Only one version control system (git) can be configured per workspace, but multiple workspaces can share the same repository. Please see the following link for more information: https://www.terraform.io/docs/cloud/vcs/github-app.html # A user has created 3 different workspace which maps to each different regions like dev, staging and prod environments. Currently he is in default workspace how can he change his workspace to prod? 1. [x] terraform workspace select prod > because to switch to workspace we use select option. The terraform workspace select command is used to choose a different workspace to use for further operations. The named workspace must already exist. 1. [ ] terraform workspace switch prod > because there is no option called switch under workspace command. 1. [ ] terraform workspace select terraform.tfstate.d/prod > because this the wrong usage of option select. 1. [ ] terraform workspace switch terraform.tfstate.d/prod > because there is no option called switch under workspace command. > For more information: https://www.terraform.io/docs/commands/workspace/select.html # How to save destroy plan to a file before destroying it? 1. [ ] terraform plan -destroy > because it only displays the plan in the console and does not save it to a file. 1. [ ] terraform plan > Because this command is used to create an execution plan. Unless explicitly disabled, Terraform performs a refresh and then determines what actions are required to achieve the desired state specified in the configuration files. 1. [ ] terraform plan –out=PATH > because the generated execution plan is saved in the path specified by this command. This isn't just for destroying things; it also includes the entire execution plan. 1. [x] terraform plan –destroy –out=PATH > this plan will be generated to delete all resources managed by the given configuration and state and save them in the PATH specified. When you run terraform plan –destroy, a plan for destroying all resources managed by the given configuration and state is generated and displayed in the console. PATH should be specified with the –out option if we want to save the state. > https://www.terraform.io/docs/commands/plan.html#destroy > https://www.terraform.io/docs/cli/commands/destroy.html # You want to validate the current configuration files of a directory. However, you don’t want to access the backend. How will you validate your Terraform configuration? 1. [x] terraform init -backend=false && terraform validate > You must use terraform init to initialise the working directory with any referenced plugins and modules in order to validate the configuration. If you don't want to initialise the backend, add the -backend=false flag to the terraform init command. 1. [ ] terraform validate -backend=false > This flag does not exist 1. [ ] terraform validate > because you must first use terraform init to initialise the working directory. 1. [ ] terraform init -backend=false -validate > because you must first initialise before running terraform validate. > References: https://www.terraform.io/cli/commands/validate#command-validate
> https://www.terraform.io/cli/commands/init#backend-initialization # You want to destroy the specific resource `module.S3.aws_s3_bucket.this[0]` of your terraform state. How can you do this? 1. [ ] terraform destroy module.S3.aws_s3_bucket.this[0] > because it causes a Syntax Error 1. [ ] terraform destroy --state=module.S3.aws_s3_bucket.this[0] > because it is not applicable to terraform destroy. 1. [ ] terraform destroy -target=aws_s3_bucket.this[0] > Because you want to destroy a specific resource created in a module 1. [x] terraform destroy -target=module.S3.aws_s3_bucket.this[0] > You must first select the resource you want to delete. It is also permissible to have multiple targets. > Reference: https://learn.hashicorp.com/tutorials/terraform/resource-targeting?in=terraform/cli # You're a DevOps Engineer who wants to use Jenkins Pipelines and Terraform to automate the provisioning of your IaC. What would be the next step in your Pipeline to work with Terraform and initialise the Terraform work directory after checkouting the repository with your Terraform code? 1. [ ] terraform validate > because terraform validates the configuration but does not initialise the Terraform backend 1. [x] terraform init 1. [ ] terraform plan > because we need to install the plugins, providers, and clone the module that we will use before doing a plan or applying our infrastructure. 1. [ ] terraform apply . > because we need to install the plugins, providers, and clone the module that we will use before doing a plan or applying our infrastructure. Terraform init A is incorrect because terraform validates the configuration but does not initialise the Terraform backend C and D are incorrect because we need to install the plugins, providers, and clone the module that we will use before doing a plan or applying our infrastructure. > Reference: https://learn.hashicorp.com/tutorials/terraform/aws-build#initializethe-directory # terraform validate checks and validate the access to the terraform state and remote states 1. [ ] True 1. [x] False Correct Answer: B terraform validate just checks if the terraform code is syntactically valid without access to remote states A is incorrect because validate just check the terraform code syntactically > Reference: https://www.terraform.io/docs/cli/commands/validate.html # You're a DevOps Engineer who wants to use Jenkins Pipelines, GitHub, and Terraform to automate the provisioning of your IaC. You have a variable called commit hash that is assigned to all of your infrastructure's AWS resources as a tag. What is the best way to specify this variable during the planning stage? 1. [ ] You have to edit your variables files before executing a plan 1. [ ] You can’t assign single values during your execution plan 1. [x] terraform plan -var ‘commit_hash=my_commit_hash_value’ 1. [ ] terraform plan -var commit_hash=my_commy_hash_value Correct Answer: C When you want to set a value into a variable during the plan or the apply A, Terraform uses the argument -var 'variable=value'. This is incorrect because you don't need to edit the variables file configuration to change the value of your variables. You can do it with the '-var' argument, but B is incorrect because you can assign variables and execute executions during the plan. Due to a syntax error, D is incorrect (Missing quotes) > Reference: https://www.terraform.io/docs/cli/commands/plan.html#var-39-foobar-39- # When you run terraform apply, Terraform will ask you to approve your infrastructure in an interactive manner. How are you going to get around this approval? 1. [ ] terraform apply -force=yes 1. [ ] terraform apply -yes 1. [ ] terraform apply -approve=yes 1. [x] terraform apply -auto-approve Correct Answer: D You can skip the interactive approval of your terraform apply execution by using the flag -auto-approve. The flags A, B, and C are incorrect because they don't exist as terraform apply arguments. > References: > https://www.terraform.io/docs/cli/commands/apply.html#auto-approve > https://www.terraform.io/docs/cli/commands/apply.html#usage # How can you destroy a particular resource of your state during the terraform destroy execution? 1. [x] terraform destroy -target=RESOURCE_TYPE.NAME 1. [ ] terraform destroy -resource=RESOURCE_TYPE.NAME 1. [ ] terraform destroy RESOURCE_TYPE.NAME 1. [ ] terraform destroy will destroy all the infrastructure based on our terraform state. You can’t specify a single resource Correct Answer: A A is the correct answer because you can specify a single resource (or multiple resources) as a target for your terraform destroy. Because this argument does not exist, B is incorrect. Because you must specify a flag where you pass your arguments, C is incorrect. D is incorrect, because the "-target" argument can be used to change this assumption. > References: > https://www.terraform.io/docs/cli/commands/destroy.html > https://www.terraform.io/docs/cli/commands/plan.html#resourcetargeting # What is the default directory where terraform fmt will be applied by default? 1. [ ] All the directories and subdirectories in our terraform working directory where the command is applied 1. [x] The current directory where the command is being applied 1. [ ] The directory defined by the environment variable TERRAFORM_FMT 1. [ ] All the above Correct Answer: B terraform fmt will be applied in the current directory by default. > References: > https://www.terraform.io/docs/cli/commands/fmt.html A is incorrect because the flag -recursive must be specified. C is incorrect because Terraform does not understand this environment variable. D is incorrect because both A and C are incorrect. # How can you taint the following resource in Terraform manually: resource "aws_s3_bucket" "mylab_bucket" { bucket = "mylab_buckett" acl = "private" tags = { Name = "mylab_bucket" } } 1. [ ] terraform taint --resource aws_s3_bucket.mylab_bucket > Because the flag —resource isn't valid on this command, 1. [ ] terraform taint --resource aws_s3_bucket.mylab_bucket.name > Because the flag —resource isn't valid on this command, 1. [ ] terraform taint aws_s3_bucket.mylab_bucket.name > because you only need to specify the resource type and name in your terraform files, not the resource name. 1. [x] terraform taint aws_s3_bucket.cncf_bucket > To taint a resource manually in Terraform, type: terraform taint[resource]. > Reference: https://www.terraform.io/docs/cli/commands/taint.html # What are the changes to be done inside the resource module when you use terraform import: 1. [ ] Nothing else. Terraform will also import the block configuration into your configuration files > because terraform import only adds the resource to the terraform state; you must write the resource block definition in your code to make it consistent. 1. [ ] Update your terraform state adding this new resource > because when you use terraform import to import your resources, the terraform state is updated. 1. [x] Write the resource configuration where the object imported will be mapped > With the current terraform implementation you only can import the resources to the Terraform state. To make it consistent, you have to write the configuration block in the terraform files > Reference: > https://www.terraform.io/docs/cli/import/index.html # You're the leader of a company's DevOps team, and you're responsible for defining multiple environments (prod, stg, dev). You've read about Terraform workspaces as a way to isolate different Terraform states and want to use them as a code definition in your infrastructure. How can you associate these local states to a new workspace if you already have different states stored locally per environment? 1. [ ] ```terraform terraform workspace new state -state=prod.tfstate prod terraform workspace new state -state=stg.tfstate stg terraform workspace newstate -state=dev.tfstate dev ``` > because the terraform workspace new state does not exist due to a syntax error definition. 1. [ ] ```terraform terraform state new -state=prod.tfstate prod terraform state new -state=stg.tfstate stg terraform state new -state=dev.tfstate dev ``` > Because you don't have the flag "new" when you run terraform state 1. [ ] ```terraform terraform workspace -state=prod.tfstate prod terraform workspace -state=stg.tfstate stg terraform workspace -state=dev.tfstate dev ``` > because you are not creating a new terraform workspace. 1. [x] ```terraform terraform workspace new -state=prod.tfstate prod terraform workspace new -state=stg.tfstate stg terraform workspace new - state=dev.tfstate dev ``` > Reference: https://www.terraform.io/docs/cli/commands/workspace/new.html # How can you list all the resources created on your Terraform State? 1. [ ] terraform state list * > because the terraform state list command does not support wildcards. 1. [ ] terraform state list --all-resources > incorrect because the flag —all-resources does not exist on the terraform state list definition. 1. [ ] terraform list --all-resources > because the terraform state list command does not support wildcards. keyword `state` is missing 1. [x] terraform state list > The terraform state list command is used to list all resources in your terraform state. > Reference: https://www.terraform.io/docs/cli/commands/state/list.html # What is the command to switch to the workspace "app-stg" 1. [x] terraform workspace select app-stg > The only options using the command terraform workspace are: ```terraform $ terraform workspace Usage: terraform workspace new, list, show, select and delete Terraform workspaces. ``` 1. [ ] terraform workspace app-stg > because in order to interact with the workspace, you must select a keyword. 1. [ ] terraform workspace choose app-stg > because Terraform Command Line does not have a workspace choose option. 1. [ ] terraform w -s app-stg > because it is not available on the Terraform Command Line. # Is switching between Terraform Workspaces possible? Can we switch the workspace while working with the 'default workspace' to 'Workspace A' and vice versa if we have 'Workspace A' and a 'default workspace'? 1. [ ] False 1. [x] True > Use terraform workspace select command to switch between workspaces. > https://www.terraform.io/docs/cli/commands/workspace/select.html # You're a DevOps Engineer working in a Jenkins-based CI/CD pipeline. You've identified three stages: initiate, plan, and implement. After you've completed your terraform plan, you'll need to set up your infrastructure. You basically wrote "terraform apply" in your pipeline script. You can see that there was no progress after triggering the pipeline, and the Apply stage is waiting for the changes to be confirmed. When you type "terraform apply," how can the changes be applied automatically? 1. [x] terraform apply -auto-approve > is the best option. This flag is used to bypass the interactive auto-approve. 1. [ ] terraform apply -yes > This flag does not exist 1. [ ] terraform apply | echo "yes" > because it is not part of the Terraform best practises and does not interact with Terraform output. 1. [ ] terraform apply | yes > because it will result in a command line syntax error. > Reference: https://www.terraform.io/cli/commands/apply#auto-approve # You're using AWS as a cloud provider, and the backend and locking are handled by S3 and DynamoDB, respectively. Because DynamoDB is unavailable, you'll need to plan your Terraform infrastructure so that you can make changes later. In this case, how will you plan your infrastructure? 1. [x] terraform plan -lock=false > You have to disable the locking during your plan execution. However, this is a dangerous option if your DynamoDB locking is working. The rest of the options are incorrect as those flags don't exist. 1. [ ] terraform plan -lock=state 1. [ ] terraform plan -no-lock 1. [ ] terraform plan -no-backend > Reference: https://www.terraform.io/cli/commands/plan#lock-false