A team created an S3 bucket by hand and now wants Terraform to manage it. The adoption must show up in a normal terraform plan for review before anything is applied, and the bucket must land in state at an address the team chooses. Which approach fits?
Answer: B. An import block names the remote object ID and the resource address it should occupy, and terraform plan previews the import before apply records it in state. refresh only updates objects already in state, a moved block renames addresses that are already in state, and taint marks an existing managed object for replacement. Source: Import existing resources, import block (https://developer.hashicorp.com/terraform/language/import)
An EC2 instance managed by Terraform has become degraded, although its configuration has not changed. The team wants Terraform to destroy and recreate only that one instance, aws_instance.web, on the next run without editing any configuration. Which command does this?
Answer: D. The -replace=ADDRESS option plans to replace the named resource instance, which suits a degraded remote object that should be rebuilt from the same configuration. state rm only forgets the object, leaving the old instance running while a new one is created, a refresh-only plan updates state without replacing anything, and validate only checks syntax. Source: Terraform CLI: plan command, -replace option (https://developer.hashicorp.com/terraform/cli/commands/plan)
Developer laptops and the CI runner must install exactly the same provider versions on every terraform init, and any change to those selections must be visible in code review. What should the team do?
Answer: A. The dependency lock file records the provider versions and checksums that init selected, and the documentation advises committing it so dependency changes go through code review. Constraints alone still allow newer releases to be selected, the .terraform directory is a local cache that is not reviewable as a selection record, and -upgrade deliberately ignores the recorded selections. Source: Dependency Lock File (.terraform.lock.hcl) (https://developer.hashicorp.com/terraform/language/files/dependency-lock)
Q4 · Terraform Advanced, collaborative workflows (TFA-3), sharing data with remote state
Team A keeps ownership of a network configuration whose state is in an S3 backend and publishes vpc_id as a root module output. Team B must read that value in a separate configuration, using Terraform's built-in way to read another configuration's state. Which approach works?
Answer: C. The terraform_remote_state data source reads the latest state snapshot and exposes only root module output values through its outputs attribute. Resources in another configuration cannot be referenced by address, importing the VPC would put one object under two states, and the data source never exposes resource data, only root-level outputs. Source: The terraform_remote_state Data Source (https://developer.hashicorp.com/terraform/language/state/remote-state-data)
Developers install providers from an internal filesystem mirror on macOS (darwin_arm64), so the committed lock file holds hashes for that platform only. A Linux (linux_amd64) CI job now fails provider verification. The team wants to keep the provider versions already selected. What should they run?
A team runs Terraform in HCP Terraform against AWS. Security forbids long-lived AWS access keys stored in workspace variables, and each run should authenticate with short-lived credentials. Which configuration meets this?
Answer: B. Dynamic provider credentials use HCP Terraform's OpenID Connect integration: with TFC_AWS_PROVIDER_AUTH set to true and a run role ARN, each run assumes the role with a short-lived identity token. A rotated key pair is still a long-lived secret held by the workspace, keys in provider blocks end up in version control, and a hand-renewed token is neither automatic nor per run. Source: Use dynamic credentials with the AWS provider (https://developer.hashicorp.com/terraform/cloud-docs/dynamic-provider-credentials/aws-configuration)
An HCP Terraform policy that forbids public S3 buckets must stop a run when it fails. A designated platform team that holds the manage policy overrides permission must still be able to override a failure and let the run continue. Which Sentinel enforcement level should the policy use?
Q8 · DOP-C02 SDLC automation (1.4), deployment strategies for serverless
A team deploys a Lambda function behind an alias with AWS CodeDeploy. It wants 10 percent of traffic on the new version for 5 minutes and then the remaining 90 percent, with an automatic rollback if a CloudWatch error alarm goes into ALARM. Which setup meets this?
Q9 · DOP-C02 configuration management and IaC (2.1), CloudFormation DeletionPolicy
A CloudFormation stack contains an S3 bucket that holds audit logs. When the stack is deleted, the bucket and its objects must remain while every other resource in the stack is removed. What should the template specify?
Q10 · DOP-C02 configuration management and IaC (2.1), CloudFormation CreationPolicy
A template launches an EC2 instance whose user data installs software. The stack must not mark the instance CREATE_COMPLETE until the installation reports success, and creation must fail if no success signal arrives within 15 minutes. What should the template use?
Answer: B. A creation policy holds a resource out of CREATE_COMPLETE until the required number of success signals arrives or the timeout passes, and cfn-signal sends the signal. DependsOn only orders resource creation, an update policy applies only to updates, and the Init metadata configures the instance without making the stack wait for a signal. Source: CreationPolicy attribute (https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-attribute-creationpolicy.html)
Q11 · CKA Cluster Architecture, Installation and Configuration, highly available control plane
An administrator builds a highly available cluster with kubeadm and keeps the default stacked etcd topology. The cluster must keep working if any one control plane node fails. What is the minimum number of control plane nodes to provision?
Answer: C. With stacked etcd every control plane node also runs an etcd member, and etcd needs a majority to agree, so the documented minimum for a highly available cluster is three stacked control plane nodes. One node is a single point of failure, two members lose the majority when either fails, and four is not the minimum because an even count gives no extra fault tolerance over three. Source: Options for Highly Available Topology (https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/ha-topology/); etcd FAQ, why an odd number of members (https://etcd.io/docs/v3.5/faq/)
Q12 · CKA Cluster Architecture, Installation and Configuration, RBAC
A Role named pod-reader that allows get and list on Pods already exists in the dev namespace. The qa-team group needs exactly that access in dev and nowhere else. Which object grants it?
Answer: D. A RoleBinding grants the permissions of a Role within its own namespace, and it may reference any Role in the same namespace, with the group listed as a subject. A ClusterRoleBinding can reference only a ClusterRole and would grant access cluster-wide, a RoleBinding cannot reference a Role from another namespace, and a Role holds rules, not subjects. Source: Using RBAC Authorization, Role and ClusterRole, RoleBinding and ClusterRoleBinding (https://kubernetes.io/docs/reference/access-authn-authz/rbac/)