Task 1.3: Explain how Terraform manages multi-cloud, hybrid cloud, and service-agnostic workflows

• AOne write, plan and apply workflow, with a provider for each platform

  Correct

  Terraform lets you use the same workflow to manage multiple providers, which simplifies multi-cloud management.

• BA single cross-cloud resource type that deploys the same server definition to either cloud

  Incorrect

  Terraform does not provide one abstract server type; each provider has its own resource types with their own arguments.

• CA converter that turns each cloud's native templates into the other cloud's format

  Incorrect

  Terraform does not translate between cloud template formats; it manages resources through providers.

• DA service that keeps both clouds' resources identical by copying changes between them

  Incorrect

  Terraform changes what its configuration describes. It does not mirror one cloud's infrastructure into another.

The multi-cloud value of Terraform is a consistent workflow and language; the resources themselves stay provider-specific.

• AOne configuration can declare resources from several cloud providers and apply them in one run

  Correct

  A configuration may require and use many providers; Terraform plans and applies them together.

• BMoving a workload to another cloud still means writing that cloud's own resource types and arguments

  Correct

  Resource types belong to a provider (an AWS instance and an Azure virtual machine are different types), so the configuration is rewritten for the new provider.

• CA resource written for one cloud's provider can be deployed to another cloud by changing only the provider block

  Incorrect

  The provider block configures one provider; it cannot make that provider's resource types work on another platform.

• DTerraform requires all providers in one configuration to come from the same publisher

  Incorrect

  A configuration can mix official, partner and community providers from different namespaces.

• EUsing more than one cloud forces each cloud's resources into a separate Terraform state file

  Incorrect

  Nothing requires one state per provider; a single state can hold resources from several providers.

Terraform unifies the workflow, not the resources: one run can span clouds, but each resource is written for its own provider.

• AThe Terraform Registry, which lists public providers

  Correct

  All publicly available providers are on the Terraform Registry, from cloud platforms to SaaS tools.

• BThe output of terraform providers in an empty directory

  Incorrect

  terraform providers lists the providers a configuration requires; an empty directory requires none.

• CThe .terraform directory of any existing project

  Incorrect

  That holds only the providers a particular project installed.

• DThe terraform version output, which lists every supported provider

  Incorrect

  version shows the installed Terraform and the providers in the current working directory, not every provider that exists.

Service coverage is a question of providers, and the Registry is where they are published.

• ATerraform signs in once with a single account and passes the token to every provider

  Incorrect

  There is no shared Terraform account for providers; each platform has its own credentials.

• BThe DNS provider reuses the cloud provider's credentials because both are in one configuration

  Incorrect

  Providers do not share credentials; each reads its own settings.

• CEach provider is configured and authenticated separately

  Correct

  Each provider has its own configuration, including how it authenticates; one provider's credentials do not apply to another.

• DAuthentication happens during terraform init and is stored in the dependency lock file

  Incorrect

  The lock file records provider versions and checksums, never credentials.

A multi-provider configuration has one configuration, and one set of credentials, per provider.

• AOne provider block that lists all four platforms

  Incorrect

  Each provider has its own block; no provider block covers several platforms.

• BThe local backend on a shared network drive

  Incorrect

  A file share stores state but gives no run history or access control per action.

• CA separate Terraform installation and state store for each cloud, one per team

  Incorrect

  That multiplies the places to look instead of centralizing them.

• DHCP Terraform, with shared state, run history and access controls

  Correct

  HCP Terraform manages Terraform workflows across teams with shared state, role-based access controls and a consistent run environment, independent of the provider.

The workflow is provider-agnostic, and so is HCP Terraform: one place for runs, state and permissions across every platform.

• AA provisioner on every service host that edits the firewall over SSH

  Incorrect

  Provisioners are a last resort and would bypass the SDN's provider.

• BConsul-Terraform-Sync generating and applying network changes as services register

  Correct

  Consul-Terraform-Sync can generate Terraform configuration to adjust ports and settings on any SDN with a provider when a service registers.

• CA data source that changes the firewall when Terraform reads it

  Incorrect

  Data sources only read; they never change infrastructure.

• DA scheduled terraform destroy of the network each night so it is rebuilt with the new ports

  Incorrect

  Destroying the network nightly would cause outages and is not how service changes are handled.

Because SDNs have providers, network changes can follow service changes automatically instead of waiting for tickets.