Cloud / AWS Management Console Interview questions

The AWS Management Console is the browser-based interface for creating, configuring, and monitoring AWS resources. Instead of typing CLI commands or writing SDK code, you click through service consoles such as EC2, S3, and IAM.

It lives at console.aws.amazon.com and is also available as a mobile app. Behind every button the console calls the same service APIs the CLI uses, so your IAM permissions apply and each action shows up in CloudTrail.

It is great for learning, quick fixes, and visual dashboards. For repeatable deployments, most teams move to infrastructure as code.

You can sign in as the root user with the account email, or as an IAM user with the account ID (or alias), user name, and password. Workforce users in larger organizations normally sign in through IAM Identity Center or their corporate identity provider instead.

1. Open the sign-in page or your account-specific URL, such as https://<account-id-or-alias>.signin.aws.amazon.com/console.
2. Choose the user type (root or IAM user).
3. Enter the credentials.
4. Complete the MFA prompt if MFA is enabled.
5. Pick a Region and open the service you need.

Access keys are not used for console sign-in. They are meant for the CLI, SDKs, and API calls.

The root user is the identity created when you open an AWS account. You sign in with the email address used at sign-up, and it has complete, unrestricted access to every resource and to billing and account settings.

IAM policies cannot limit the root user of a standalone account, which is exactly why it is risky. In AWS Organizations, service control policies (SCPs) can restrict the root user of member accounts.

Best practice is to lock it down: a strong unique password, MFA, no access keys, and use only for the few tasks that truly require it.

An account alias is a friendly name that replaces the 12-digit account ID in your IAM sign-in URL. With an alias of acme-prod, users sign in at https://acme-prod.signin.aws.amazon.com/console.

The alias must be globally unique across AWS and can contain lowercase letters, digits, and hyphens. An account can have only one alias at a time, and you create it from the IAM dashboard.

The original account-ID-based URL keeps working after you create an alias.

The Region selector is the drop-down in the top navigation bar that decides which AWS Region the console talks to. Most services, including EC2, RDS, and Lambda, are regional, so you only see resources that exist in the selected Region.

The console remembers your last choice, and the Region also appears in the URL, for example us-west-2.console.aws.amazon.com. Picking the wrong Region is the most common reason people think a resource has disappeared.

Global services such as IAM show Global in place of a Region name.

Global services are not tied to a single Region, so their console pages show a Global label and ignore the Region selector. Examples are IAM, AWS Organizations, Route 53, CloudFront, and the Billing console.

Be careful with the exceptions. S3 shows one list of buckets, but each bucket lives in a specific Region. Many global services also keep their control plane in us-east-1.

Console Home is the landing page after sign-in. It is a dashboard of widgets that you can add, remove, and rearrange to fit your workflow.

Common widgets include Recently visited, Applications, Cost and usage, AWS Health, and Trusted Advisor. The Recently visited widget gets you back to your last-used services in one click, and the layout can be reset to default at any time.

Use the search bar at the top of the console. Type a service name, feature, or even a task, and it returns matching services, features, documentation, and, if Resource Explorer is set up, resources.

The keyboard shortcut Alt+S (Option+S on Mac) jumps the cursor to the search box. You can also star services in the Services menu so they appear as favorites in the navigation bar.

The AWS Console Mobile Application is the official iOS and Android app for checking on your AWS environment while away from a desk. You can view resources, check CloudWatch alarms, see billing information, and perform limited operational actions on some services.

It supports sign-in with IAM user credentials, root credentials, or federated access, and can protect saved identities with device biometrics. It does not expose every service, so treat it as a monitoring companion rather than a full replacement for the web console.

AWS CloudShell is a browser-based shell you open directly from the console toolbar. It is already authenticated with the credentials you used to sign in, so you can run aws commands without configuring access keys.

The environment comes with the AWS CLI, Python, Node.js, git, and other common tools. It supports Bash, Zsh, and PowerShell, and you get 1 GB of persistent storage in your home directory per Region at no extra charge.

The Billing and Cost Management console is where you view bills and invoices, manage payment methods, and track what your usage is costing. It includes Cost Explorer, Budgets, Cost Allocation Tags, and Free Tier usage tracking.

You open it from the account menu in the top-right corner. By default only the root user can see it, and IAM users need billing access activated by the root user before they can.

The AWS Health Dashboard shows what is happening with AWS services and with your own resources. It has two views: Service health for public, Region-wide events and Your account health for events that affect the resources in your account.

Account health covers scheduled maintenance, instance retirements, certificate expirations, and issues needing action. Open it from the bell icon in the console header.

Tag Editor, part of Resource Groups & Tag Editor, lets you find resources across multiple Regions and services and then add, edit, or remove tags in bulk.

You search by Region, resource type, and optional tag filters, then select results and manage their tags together. It is handy for fixing missing cost-allocation tags without opening each service console, though not every resource type supports tagging.

A Resource Group is a collection of AWS resources that you treat as one unit. There are two kinds: tag-based groups, which gather every resource matching a tag query, and CloudFormation stack-based groups, which gather the resources in a stack.

Once grouped, you can view them together in the console and run Systems Manager actions against the whole group. For example, a group built from the tag Environment=Dev shows all dev resources in one place.

Open the user in IAM and register an authenticator from the Security credentials tab. The user can also do this themselves from the account menu.

1. Go to IAM > Users and select the user.
2. Open Security credentials and choose Assign MFA device.
3. Enter a device name and pick the type: passkey or security key, authenticator app, or hardware TOTP token.
4. Follow the prompts, entering two consecutive codes for an app or token.
5. Choose Add MFA and confirm the device is listed.

An IAM user can register up to eight MFA devices.

In the IAM console choose Users > Create user. Tick Provide user access to the AWS Management Console and set up the sign-in details.

1. Enter a user name.
2. Choose an auto-generated or custom password and decide whether to require a change at next sign-in.
3. Add the user to a group or attach policies.
4. Add optional tags and review.
5. Create the user and download or email the sign-in instructions.

AWS recommends IAM Identity Center for people, so create IAM users mainly for cases where it can't be used.

Check the Region first, then open EC2 > Instances > Launch instances.

1. Name the instance and add tags.
2. Choose an AMI such as Amazon Linux.
3. Pick an instance type like t3.micro.
4. Select or create a key pair, or skip it if you plan to use Session Manager.
5. Configure network settings: VPC, subnet, and a security group.
6. Set storage and review the summary.
7. Choose Launch instance.

The new instance appears in the Instances list and goes from pending to running.

Open S3 > Buckets > Create bucket, enter a bucket name that is unique across all of AWS, and select a Region. The Region matters because the bucket stays there.

Review the defaults: Block Public Access is on, ACLs are disabled through the bucket owner enforced setting, and new objects are encrypted with SSE-S3. Optionally enable versioning and tags, then choose Create bucket.

Service Quotas is the console where you view the limits applied to your account for each AWS service and request increases when a quota is adjustable.

You can see both the default value and your applied value per Region. You can also create CloudWatch alarms that fire as usage approaches a quota, which helps avoid surprise failures, such as being unable to launch instances.

Trusted Advisor inspects your account and recommends improvements in areas like cost optimization, performance, security, fault tolerance, service limits, and operational excellence.

It is available in the console, and a limited set of core checks is included with Basic and Developer support. The complete set of checks requires a Business, Enterprise On-Ramp, or Enterprise support plan. A typical finding is an idle load balancer or a security group open to the world.

Go to IAM > Account settings > Password policy and choose Edit. The policy applies to all IAM users in the account, not to the root user.

• Minimum length (up to 128 characters)
• Require uppercase, lowercase, numbers, and symbols
• Password expiration from 1 to 1,095 days
• Prevent reuse of up to 24 previous passwords
• Allow users to change their own password
• Require administrator reset after expiry

Consider stronger MFA instead of aggressive expiry rules.

Click your account name in the top-right corner of the console. The 12-digit account ID is shown in the menu, with a copy icon beside it.

It also appears on the IAM dashboard and the Account page. From the CLI, run aws sts get-caller-identity and read the Account field. The ID identifies the account but is not a secret.

The Support Center is where you open and track cases with AWS Support. Account and billing cases are available to every customer.

Technical support cases need a Developer, Business, Enterprise On-Ramp, or Enterprise plan, and the plan also sets response times. The Support Center also links to Trusted Advisor and the Health Dashboard, so many issues can be checked before a case is opened.

Use AWS Organizations to manage multiple AWS accounts centrally. From the management account's console you can create or invite accounts, group them into organizational units (OUs), and attach service control policies (SCPs) that set permission guardrails.

It also provides consolidated billing, so one payer account is billed for all member accounts and volume discounts are shared. Several AWS services integrate with it for organization-wide setup.

AWS offers several access methods, and they all end in the same service APIs.

All three call the same AWS APIs. They differ in how you drive them and how repeatable the result is.

A common path is to prototype in the console, then convert the working setup to CLI scripts or IaC.

The root user has unrestricted access, and IAM policies cannot limit it in a standalone account. If those credentials leak, the attacker can change billing, delete every resource, and even close the account.

Daily work should use IAM Identity Center or IAM roles with least-privilege permissions, so a mistake or compromise stays contained. Separate identities also give clean audit trails, because CloudTrail shows who did what.

• Enable MFA on the root user and remove root access keys.
• Store the password and MFA device in a secured, shared-control location.
• Sign in as root only for tasks that require it.

A small set of account-level tasks can only be done as the root user. Examples include:

• Changing the account name, root email, or root password
• Closing the AWS account
• Changing or canceling an AWS Support plan
• Restoring IAM permissions when no one else can manage IAM
• Activating IAM access to the Billing console
• Editing or deleting an S3 bucket policy that blocks all principals

For organizations, centralized root access management lets the management account perform privileged root actions on member accounts without keeping root credentials for each one. This lets teams remove member-account root passwords entirely.

An IAM user lives inside a single account with its own long-lived password. IAM Identity Center gives workforce users one sign-in portal that reaches many accounts, using temporary credentials.

For people, Identity Center is usually the better choice because it centralizes access and removes long-term credentials.

Switch role lets a signed-in identity temporarily assume an IAM role, often in another account, without signing out.

1. Open the account menu in the top-right corner and choose Switch role.
2. Enter the 12-digit account ID (or alias) and the role name.
3. Optionally set a display name and color so you recognize the session.
4. Choose Switch Role.

It only works if the role's trust policy trusts your identity and your own permissions allow sts:AssumeRole on that role. The session length is capped by the role's maximum session duration, and the console remembers recently used roles for quick switching.

Federation lets users sign in with their corporate identity and land in the console without having an IAM user. A broker, such as your identity provider, exchanges proof of identity for temporary AWS credentials and builds a sign-in URL.

1. The user authenticates with the identity provider.
2. The broker calls STS (for example AssumeRole or AssumeRoleWithSAML) to obtain temporary credentials.
3. The broker sends those credentials to the federation endpoint to request a sign-in token.
4. The broker builds a console login URL containing the token.
5. The user is redirected and arrives in the console with the assumed role's permissions.

sequenceDiagram
  participant U as User
  participant IdP as Identity Provider
  participant STS as AWS STS
  participant FE as Federation Endpoint
  participant C as AWS Console
  U->>IdP: Sign in
  IdP->>STS: AssumeRole / AssumeRoleWithSAML
  STS-->>IdP: Temporary credentials
  IdP->>FE: Request sign-in token
  FE-->>IdP: Sign-in token
  IdP-->>U: Redirect with login URL
  U->>C: Open console as the role

The sign-in token is short-lived, about 15 minutes, so the URL must be used promptly.

CloudShell reuses the credentials of the identity signed in to the console, so a federated user gets the same permissions inside the shell as in the browser. The identity also needs permission to use CloudShell itself, such as the AWSCloudShellFullAccess managed policy.

Only your home directory persists, with 1 GB per Region. Files stored elsewhere vanish when the session ends, and installed packages outside $HOME must be reinstalled.

• Sessions end after a period of inactivity, around 20 to 30 minutes.
• Persistent storage is removed after 120 days without use in a Region.
• Files can be uploaded and downloaded from the Actions menu.

The Instances page has a Connect button that offers several browser-based options, each with different prerequisites.

For production, Session Manager is generally favored because it avoids opening SSH to the internet.

The SSM Agent on the instance opens an outbound HTTPS connection to Systems Manager, and your browser session is relayed through that channel. Nothing connects inbound to the instance, so no port 22 and no key pair are needed.

• SSM Agent installed and running (preinstalled on many Amazon-provided AMIs)
• An instance profile with AmazonSSMManagedInstanceCore
• Outbound 443 to the SSM, SSM Messages, and EC2 Messages endpoints, or matching VPC endpoints
• The user allowed to call ssm:StartSession

Session activity can be logged to S3 or CloudWatch Logs, and StartSession shows up in CloudTrail, giving you a stronger audit trail than plain SSH.

When you click Connect, EC2 Instance Connect pushes a one-time public key to the instance metadata. That key stays valid for only 60 seconds, and the instance's SSH daemon fetches it to authenticate your browser session.

The caller needs the ec2-instance-connect:SendSSHPublicKey permission, and the security group must allow port 22 from the EC2 Instance Connect service IP range for that Region. It is supported on Amazon Linux and Ubuntu AMIs.

For instances without public IPs, an EC2 Instance Connect Endpoint can provide access from the console without a bastion host.

Use a policy that denies everything except a few self-service actions unless the request was authenticated with MFA. The key is the condition aws:MultiFactorAuthPresent.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyAllExceptMfaSetupWithoutMFA",
    "Effect": "Deny",
    "NotAction": [
      "iam:CreateVirtualMFADevice",
      "iam:EnableMFADevice",
      "iam:ListMFADevices",
      "iam:ListVirtualMFADevices",
      "iam:ResyncMFADevice",
      "iam:ChangePassword",
      "iam:GetUser",
      "sts:GetSessionToken"
    ],
    "Resource": "*",
    "Condition": {
      "BoolIfExists": { "aws:MultiFactorAuthPresent": "false" }
    }
  }]
}

BoolIfExists matters: it also denies requests where the key is missing, such as long-term access keys. Attach the policy to a group so new users inherit it.

When a resource seems to have vanished, it is usually hidden rather than deleted. Work through these checks in order:

1. Confirm the Region selector matches where the resource was created.
2. Check the account ID and role shown in the account menu, in case you switched roles.
3. Clear filters, such as an Instance state filter that hides stopped instances.
4. Verify your IAM permissions for the list or describe actions.
5. Search across Regions with Tag Editor or Resource Explorer.
6. Look in CloudTrail for a delete event if the resource is truly gone.

Wrong Region and wrong account together cover most cases.

The error message names the action and the resource ARN that was denied, which tells you what to fix. Some services return an encoded message that you can decode with aws sts decode-authorization-message, which requires sts:DecodeAuthorizationMessage permission.

Then check each layer that could block the call:

• Identity-based policies on your user, group, or role
• Permissions boundary on the identity
• Service control policies from AWS Organizations
• Session policies from a role or federated session
• Resource-based policies, such as an S3 bucket policy
• Any explicit Deny, which always wins

The IAM Policy Simulator helps test the combination before you edit anything.

Use CloudTrail. Every console sign-in produces a ConsoleLogin event that records who signed in, from which IP, whether it succeeded, and whether MFA was used. Console actions are logged as ordinary API events, with a user agent that identifies the console.

The Event history view keeps 90 days of management events, and you can filter by event name or user name. For longer retention, create a trail that delivers logs to S3.

Add a CloudWatch metric filter and alarm on root user ConsoleLogin events so you are notified the moment root is used. If a sign-in event is missing, check us-east-1, since events from the default sign-in endpoint are recorded there.

Access is controlled in two layers. First, the root user must turn on IAM user and role access to Billing information on the Account page. Without that setting, even administrators are blocked.

Second, attach an IAM policy that allows the billing actions needed, such as viewing invoices or using Cost Explorer. AWS provides fine-grained actions, so you can allow Cost Explorer (ce:*) without letting someone change payment methods.

Grant billing permissions to a finance group rather than individuals, and keep payment-method changes limited to a very small set of people.

Cost Explorer is for analysis: it graphs past spend and forecasts future spend. AWS Budgets is for control: it watches spend or usage against a threshold you set and alerts you when it is crossed.

Teams usually use both: Cost Explorer to find a spike, Budgets to catch the next one.

Regions launched after March 20, 2019, plus a few older ones like Hong Kong and Cape Town, are disabled by default. You must opt in before resources can be created there.

1. Sign in as root or as an IAM principal with account:EnableRegion permission.
2. Open the account menu and go to Account.
3. Find the AWS Regions section.
4. Select the Region and choose Enable.

Enabling can take several minutes to hours. During that time the Region cannot be used, and IAM data is replicated to it automatically.

Console Private Access lets users reach the console from inside a VPC or from on-premises over private connectivity instead of the public internet. It uses AWS PrivateLink interface endpoints for the console and sign-in services.

The security benefit is control over which accounts can be signed in to from your network. You list the allowed account IDs, and sign-ins to any other account are blocked, which reduces the risk of employees moving company data into personal AWS accounts.

flowchart LR
  A["Corporate network"] --> B["VPN or Direct Connect"]
  B --> C["VPC interface endpoints"]
  C --> D["AWS Console and Sign-in"]
  C -.-> E["Allowed accounts only"]

Console-to-Code records what you do in the console and turns it into reusable code. You start a recording, perform the actions, stop it, and review the list of recorded API calls.

It then generates code in formats such as the AWS CLI, CloudFormation, and CDK, using generative AI to produce the output. Support started with EC2 and has been growing to more services.

Treat the result as a starting point. Review parameters, remove hard-coded IDs, and test it before using it in a pipeline.

The console supports multi-session, which lets you stay signed in to up to five accounts or roles at once in the same browser. You enable it from the account menu, then add sessions from the same menu.

Each session keeps its own identity and Region, and you can tell them apart by the account details in the menu. Before this feature, people relied on separate browser profiles, private windows, or Firefox containers.

Two IAM tools help you find stale credentials. The Credential report is a downloadable CSV listing every user with fields such as password_last_used, access_key_1_last_used_date, and mfa_active. It can be generated at most once every four hours.

Access Advisor, on each user and role, shows which services were last accessed so you can trim permissions that are never used. IAM Access Analyzer can also produce unused-access findings.

Remove or deactivate credentials that have not been used for 90 days or more.

AWS Resource Explorer indexes your resources so you can search them by name, tag, or type across Regions and services, without opening each console page.

You turn it on by creating indexes in the Regions you want, then designating one as an aggregator index so a single search returns results from all of them. Once configured, results show up in the console's unified search bar.

Unlike Tag Editor, which is aimed at managing tags, Resource Explorer is built for quickly finding resources, even ones you can't remember the Region for.

Choose the console for exploration and one-off work: learning a new service, investigating an incident, viewing graphs, or doing tasks that need root. Choose CLI or IaC when the result must be repeatable, reviewed, and versioned.

The danger of manual clicking is configuration drift, because changes live only in someone's memory. Console-to-Code or a CloudFormation import can capture them afterward.

The console is a front end for service APIs. When you click Create, it signs an API request with your session credentials and sends it to the service, for example RunInstances for EC2.

The service asks IAM to evaluate the request against all applicable policies. If allowed, the resource is created and the call is recorded in CloudTrail. The console then keeps polling calls like DescribeInstances to update the status on your screen.

sequenceDiagram
  participant U as You
  participant C as Console
  participant S as Service API
  participant I as IAM
  participant T as CloudTrail
  U->>C: Click Launch instance
  C->>S: Signed RunInstances request
  S->>I: Evaluate policies
  I-->>S: Allow or Deny
  S-->>C: Resource created (pending)
  S->>T: Log the API call
  C->>S: Poll DescribeInstances
  S-->>U: Status shows running

A denied request fails at the policy step, which is why permission errors in the console match CLI errors exactly.

Layer several controls so that no single failure exposes the account.

Review access regularly with the Credential report and Access Analyzer, and remove what is unused.