Cloud Technology and Services practice questions

The AWS Command Line Interface (AWS CLI) controls AWS services through terminal commands, which can be combined into scripts for repeatable, schedulable administrative automation.

The scenario contains the two classic CLI triggers: a person's operational task performed from a terminal, and a requirement that it be scripted and scheduled to run identically every night. The CLI converts each step into a text command, so the whole sequence becomes a script that a scheduler can invoke. The Management Console fails because manual browser work cannot be scheduled and does not reproduce itself consistently. The Console Mobile Application fails for the same reason — it is a monitoring convenience for humans. Direct Connect fails because it is a network connectivity option and has nothing to do with executing administrative tasks.

1. Identify the actor and context: an administrator working from a terminal.
2. Spot the keywords: scheduled, script, runs the same way every time.
3. Match scripted, repeatable admin operations to the AWS CLI.
4. Eliminate both console options as manual human interfaces and Direct Connect as a networking service.

Exam tip: Scripted, scheduled administrative tasks from a terminal are the home turf of the AWS CLI.

AWS exposes every service as a set of API operations over HTTPS; the Management Console, CLI, and SDKs are simply different ways for humans and software to reach that single interface.

The unifying fact behind all AWS access methods is the API layer: clicking a button in the console, typing a CLI command, and calling an SDK function each result in the same authenticated API call over HTTPS. This is also why anything done manually can be automated. Browser sign-in is wrong because it applies only to the console — programmatic access uses access keys or temporary credentials. Requiring code is wrong because the console is code-free and the CLI uses commands, not programs. Declarative templates are wrong because that describes CloudFormation, a separate infrastructure-as-code approach, not something the three methods share.

1. Recall the layered model: the AWS APIs form the foundation, and every access method sits on top of them.
2. Test each option against all three methods rather than just one.
3. Note that authentication styles differ (browser versus credentials), eliminating the sign-in option.
4. Conclude that the common thread is that all methods issue the same underlying API calls.

Exam tip: Every AWS access method — console, CLI, or SDK — is a different front door to the same AWS APIs.

Programmatic access means software or scripts interacting with AWS through credentials and API calls, in contrast to a human working through a graphical interface.

The CLI and the SDKs are the two programmatic methods CLF-C02 names: the CLI turns operations into terminal commands that scripts can automate, and SDKs embed AWS API calls inside application code. Both authenticate with access keys or temporary credentials and both issue the same underlying API calls. The Management Console and its mobile application are graphical interfaces operated by people, so they are manual, not programmatic. A documented runbook is a trap answer — writing down console steps produces a manual procedure with all the same risks of typos and skipped steps, because only code executes identically every time.

1. Define programmatic: driven by scripts or application code, not human clicks.
2. Accept the CLI as programmatic because commands can be scripted and scheduled.
3. Accept SDKs as programmatic because applications call AWS directly from code.
4. Reject both console variants and the runbook because a human still performs every step manually.

Exam tip: Programmatic access to AWS means the CLI and the SDKs; the console in any form is manual.

The AWS APIs are the foundation beneath every access method; the console, CLI, and SDKs are convenience layers, and direct API calls remain possible when no higher-level tool fits.

Because AWS delivers each service as a set of HTTPS API operations, any code that can send signed web requests can use AWS — an SDK is a convenience that handles signing and retries, not a requirement. Direct API use is rare but is exactly the fallback for an environment with no SDK support. The console option fails because a browser interface cannot serve an application's runtime needs. Declaring AWS unusable is wrong because the API layer is universally reachable. The CloudFormation option fails twice: templates are JSON or YAML, not arbitrary languages, and CloudFormation provisions resources rather than serving runtime application calls.

1. Recall that SDKs are wrappers over the AWS HTTPS APIs, not the only path to them.
2. Recognize the scenario constraint: no SDK exists, but the application must call AWS directly.
3. Conclude that the application can issue signed HTTPS requests to the APIs itself.
4. Eliminate the console (human-only), giving up (the APIs are open), and CloudFormation (provisioning, wrong format).

Exam tip: When no SDK exists, code can still call the underlying AWS HTTPS APIs directly — the API is the foundation of all access.

Infrastructure as code (IaC) means describing infrastructure in machine-readable definition files; AWS CloudFormation is the AWS IaC service that turns JSON or YAML templates into provisioned stacks.

CloudFormation matches every element of the stem: templates in JSON or YAML, provisioning of many related resources, and management of them together as a single unit called a stack. Deploying the same template again produces an identical environment. The CLI is imperative — it lists commands to run in order — rather than declarative, and it has no stack concept. The console is manual and template-free. CloudFront is a deliberate name-alike distractor: it is a CDN for caching content near users and is entirely unrelated to infrastructure provisioning.

1. Spot the IaC signals in the stem: templates, JSON or YAML, resources managed as one unit.
2. Recall that CloudFormation is the AWS infrastructure-as-code service and its unit is the stack.
3. Distinguish declarative templates from the CLI's imperative commands.
4. Beware the CloudFront name trap — CDN, not IaC.

Exam tip: CloudFormation is the AWS IaC service: JSON or YAML templates in, managed stacks out.

When environments must be repeatable and consistent, infrastructure as code is the answer: a CloudFormation template defines the environment once and provisions it identically any number of times.

The stem contains the strongest IaC triggers on the exam: identical environments, recreated quickly, without manual errors. Only a machine-readable definition satisfies all three — CloudFormation deploys the same template as many times as needed, eliminating drift between environments and removing the typos and skipped steps that creep into manual work. Every distractor is a variation on manual process: careful documentation, screenshots, and extra reviewers all still depend on humans executing steps by hand, and no amount of documentation makes manual work reproduce itself exactly. Only code guarantees consistency.

1. Identify the requirement type: repeatable provisioning of whole environments.
2. Map identical plus repeatable plus error-free to infrastructure as code.
3. Select CloudFormation as the AWS IaC service that deploys a template into identical stacks.
4. Reject all manual variants — documentation and extra people do not remove human inconsistency.

Exam tip: Identical, repeatable environments call for a CloudFormation template, never a documented manual procedure.