Explore key concepts and practical scenarios in using Ansible for automating cloud infrastructure across AWS, Azure, and GCP. Assess your foundational understanding of configuration management, cloud modules, and best practices for multi-cloud automation using Ansible.
Which type of inventory allows Ansible to dynamically discover cloud resources such as instances or virtual machines for automation tasks?
Explanation: Dynamic inventory automatically retrieves information about current cloud resources, making it suitable for environments where infrastructure changes frequently. Static inventory, on the other hand, requires manually listing resources, which can become outdated quickly. Manual inventory is not a recognized Ansible concept. Host inventory simply refers to listing hosts, without dynamic capabilities.
When automating the creation of a virtual machine in a cloud environment using Ansible, which module type should you use?
Explanation: Cloud-specific modules are designed to interact with cloud providers' APIs to manage resources like virtual machines. File and copy modules are used for file management on remote servers, not resource provisioning. Shell modules execute shell commands but are not tailored for structured cloud automation.
What is a secure way to manage sensitive access keys or credentials required for running Ansible playbooks against cloud platforms?
Explanation: Ansible Vault provides encryption to protect sensitive data such as credentials, ensuring increased security. Storing credentials in playbooks or in plain text exposes them to unauthorized access, while sharing access keys in public repositories is highly insecure and never recommended.
How can Ansible playbooks help enforce consistent tagging on cloud resources during deployment?
Explanation: Specifying tag parameters directly in Ansible tasks ensures tags are applied automatically and consistently as resources are deployed. Adding tags manually increases the risk of human error. Relying solely on default tags means important contextual information may be missing. Avoiding tags undermines resource management and cost tracking.
What does it mean for an Ansible cloud automation task to be idempotent?
Explanation: Idempotent tasks ensure the infrastructure remains in the desired state, even with repeated executions, which is essential for predictable automation. Scaling servers on every run can lead to resource waste. Randomly creating or deleting resources is unpredictable. Manual confirmation negates automation efficiency.
In a scenario where both AWS and Azure resources are managed with Ansible, what is a simple way to differentiate these resources in your inventory?
Explanation: Grouping resources by provider allows tailored playbooks or variables, making management easier and organized. Listing all resources in one group loses clarity. Omitting groups provides no structure. Assigning duplicate hostnames can cause confusion and errors during automation runs.
If a cloud resource fails to create during a playbook run, which Ansible directive helps you gracefully handle the error?
Explanation: ignore_errors: yes instructs Ansible to continue with the next tasks even if the current one fails. continue_on_fail and pass_on_error are not valid Ansible parameters. skip_if_failed: yes does not exist in Ansible documentation.
Which module allows Ansible to collect information about cloud resources, such as instance attributes, for use in later tasks?
Explanation: The facts module collects detailed information about cloud resources, which can be referenced in subsequent tasks. The ping module checks connectivity. The user module manages user accounts. The wait_for module waits for conditions but does not gather detailed resource data.
When writing playbooks for multiple cloud providers, how can you avoid hard-coding values specific to each environment?
Explanation: By defining variables and using group_vars, you centralize and simplify configurations for each environment. Writing separate playbooks increases maintenance. Embedding provider names in every task reduces flexibility. Ignoring environment differences leads to errors and failures in automation.
What best describes the 'infrastructure as code' approach enabled by Ansible for cloud environments?
Explanation: Infrastructure as code means using declarative or script-based files for creating and managing infrastructure, ensuring consistency and repeatability. Manual configuration misses the automation, speed, and reliability. Automating only software installation focuses on post-provisioning, not infrastructure. Documentation alone does not automate infrastructure.